Hi Mariano,
An ajax request is indeed not different from a full request. Each request in GLASS is a transaction. So, there is no 'open transaction' when a gem is servicing an ajax request because the transaction of the original full request was closed when then response was sent.
What Dale mentions about optimizing concurrent ajax requests in GLASS is described here:
http://jbrichau.github.io/blog/when-to-use-http-session-affinity-in-glass/Ajax requests in Seaside operate on the current continuation, and should run within a transaction. But, as Dale mentions, I can imagine that if you have pure read-only GET requests, you can optimize this further and create a dedicated gem that does not commit anything. We have also not done anything like that (mostly because pure read-only ajax requests are a minority in our case).
Also, mind that an error does not perform a rollback because the default behaviour of the Gemstone Seaside error handler is to commit the debug stack to the object log. So, any change that was made is committed. This is indeed not always desirable and you could change that by handling an error differently but then you loose the logging of the debug stack.
Johan
On 11 Jun 2014, at 22:29, Dale Henrichs <
[hidden email]> wrote:
> They are treated like any other http request ...
>
> - abort
> - seaside code runs
> - commit (on conflict abort and retry)
> - only one concurrent request allowd
>
> This is not necessarily ideal and I do believe that Johan (and maybe others) have come up with better schemes for handling AJAX requests ...
>
> I think the biggest issue is that a whole bunch of AJAX requests can come flying off of a web page and that can clog up the seaside gems with a bunch of requests (basically the number of concurrent http requests can jump up) ...
>
> One scheme would involve routing readonly requests to a dedicated seaside server gem (or gems) that do not commit when servicing http requests thus allowing more than one http request to be serviced concurrently ... I've not set this up myself, but I think that the folks who have implemented these schemes in production use a variant of this approach...
>
> Dale
>
>
> On Wed, Jun 11, 2014 at 1:20 PM, Mariano Martinez Peck <
[hidden email]> wrote:
> Hi guys,
>
> As far as I understand...with Glass we get the "automatic" transaction management...a request comes...a gemstone transaction begins, a response is done, the gemstone transaction is committed. If error, I guess rollback, if conflict, retries a few times...or something like that.
>
> My question now is what happens with AJAX gets and callbacks? How do they affect the current gemstone transaction opened by the original http request?
>
> Thanks in advance,
>
> --
> Mariano
>
http://marianopeck.wordpress.com>
Locked
