I guess this is just more proof that Stripes is still not feature complete.
There are still core things that can and need improvement.
Karen
From: Ross Sargant [mailto:rsarg...@tvrc.com]
Sent: Saturday, 04 September, 2010 0:19
To: Stripes Users List
Subject: Re: [Stripes-users] Stripes Development and its Future... (long)
This is off-topic, but I've never understood why the only two standard
concurrency models are free threaded or single threaded servlets. What I
want most of the time is session level serialization of requests so that
only one transaction may run on a particular HTTP session at a time but
transactions on other http sessions may run concurrently. If this model is
used, session variables become threadsafe and it seems to work just fine
for the average web-app where the user logs in and does one thing at a time.
I actually implemented a filter in front of the stripes filter to establish
that model for the rest of my application. To avoid eating up request
processing threads, I put a limit on the amount of work that can be queued
against a particular session and a limit on how long the request will wait
for the "right to execute". With that in place, my team doesn't have to
worry about thread problems with session state and it provides some level of
double submit protection for the action beans (the 2nd submit does not run
in parallel so it will reliably see and act on the complete effects of the
first).
Is there an easier way to get the "single transaction per session" thread
model?
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
