On Thu, Nov 13, 2014 at 1:08 PM, Marko Topolnik
<marko.topolnik@gmail.com> wrote:
> Yes, your approach makes perfect sense---as long as you don't care about transactional semantics.
>
> If the transaction boundary is moved all the way to the end of serving the response, the following happens:
>
> 1. 200 OK status code reported, but transaction still not committed;
> 2. transaction may roll back due to errors in transfer;
> 3. thanks to buffering, the transfer may also fail _after_ the transaction has committed.
>
> So, not only have you established quite messy and illogical transaction semantics for your client (for example, a
typicalonSuccess callback on the HTTP request cannot assume the transaction succeeded); the client has no idea _in
principle_what happened to the transaction if transfer is aborted for any reason.
>
> In an earlier incarnation of my project I did indeed have setup exactly as you describe it, but after realizing the
aboveproblems, I had to back off and revert to standard transaction boundaries.
>
Another slightly subtler problem is the following:
1. 200 OK reported but transaction still not committed due to various
async delays
2. client makes another request assuming the transaction is committed
3. result of 2. returned fast to client, transaction in 1. still not committed
4. client doesn't see committed data
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source Content Management Platform for Business Apps
http://www.nuxeo.com http://community.nuxeo.com
