j dailey wrote:
>  I defer to those now on the list to comment - Sam?  William? Terry?
>  Jim?  Tom? Alija? 

My hazy, hazy recollection, prompted by a note from Terry, is that there 
was something a little unusual about how MIFOS handled Hibernate sessions.

The normal way web apps work is to map a single HTTP request/response 
cycle to one or more units of work from the database's perspective. So 
as the request comes in, you get a connection from the connection pool, 
you do some stuff, you commit it or roll it back, and you release the 
connection. If you've got some user activity that runs across multiple 
HTTP requests (like a wizard-style interface), you have to find ways to 
bridge the different unit-of-work lifecycles.

Another way to do things is to keep a database session (a connection, 
possibly with an open transaction) around for as long as you have an 
HTTP session. The upside is that you can have a database unit of work 
match a user unit of work more easily. The downside is that this is 
fragile and doesn't scale well.

I think early on MIFOS used the latter model. I feel like we looked at 
changing to the more standard approach, but there were some dependencies 
on the connection-per-HTTP-session approach. What has happened since, I 
have no idea. A quick search of my old email turns up nothing about 
this, so either it was only discussed verbally or I'm thinking of some 
other project entirely.

If this connection-per-HTTP-session approach is in use on MIFOS, it 
would produce intermittent failure under high load or other sorts of 
heavy use, like doing MIFOS work in multiple tabs at once.


Regardless, sounds like we could use some load tests.

William


-- 
William Pietri - [EMAIL PROTECTED] - +1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
Instant video gratification: http://www.sidereel.com/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Reply via email to