We're noticing a somewhat weird problem with our Stripes app. Many
(most) of our forms are in client-side dialogs. The dialogs aren't
complete pages; they're done with various bits of client-side magic.
An AJAX request loads a page fragment containing the form, the user
types stuff, and upon a button's click the client-side code launches
another AJAX request to POST the form. The response to the POST (when
successful) is another page fragment, which now will mostly be nothing
but a "<script>" block with a snippet of Javascript to close the
dialog and trigger reloading of other parts of the page affected by
the operation. In other words, if the page is displaying some sort of
configuration status, and a dialog provides a way to change something,
then upon closing the dialog after a successful update some other
portion of the page must be reloaded with the new (changed)
configuration stuff.
So all that generally works great, except for this one small issue
that comes up now and then. Our server-side (Stripes) environment
involves a home-grown JPA implementation and a fairly simple database
session manager. Basically all that happens is that the session gets
initialized early in the Stripes lifecycle, and then after the
"ResolutionExecution" stage is done we commit the database transaction
and clean stuff up.
The strange thing that sometimes happens is this: sometimes, the
client-side code that responds to the successful "POST" from one of
those AJAX forms manages to start a new HTTP transaction to fetch
updated stuff from the server, and that transaction manages to run
**before** the code in the previous HTTP request thread has managed to
commit the database transaction (the one responsible for the update).
To me, what that means is that the HTTP response stream must be
completed (closed? that's all I can imagine, but I'm pretty fuzzy on
exactly how the high-level Java Servlet APIs relate to the low-level
HTTP protocol and the things in particular that the browser sees to
convince it that an HTTP response is complete) before the code in our
intercept does the "commit."
Our intercept is not much more complicated than this:
Resolution rv = executionContext.proceed();
boolean closeSession = (executionContext.getLifecycleStage ==
LifecycleStage.ResolutionExecution) ||
rv == null;
// exception handling, other stuff not really relevant
if (closeSession) {
session.commit();
}
So: is it the case that somewhere inside Stripes - or inside something
else - that *after* the JSP code for our page fragment has completed,
and before that call to "proceed" returns to our intercept, the HTTP
response stream is closed? If so, is there a better place to put our
session cleanup code in the lifecycle? One fairly simple thing we've
considered is that we could commit the session after the action bean
has finished and before we get to the JSP code, leaving it in a
"semi-open" state so that page code and utility beans etc. could still
access the database read-only. That has the minor problem that
forwarding from one action bean to another would become problematic,
though that's a pretty rare thing in our application.
--
Turtle, turtle, on the ground,
Pink and shiny, turn around.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
