Hi Kieth, > The one-connection-per-http-session is certainly not scalable, Agreed
> but my > question is, how scalable does the application need to be? I am also new to MifOS but I tend to lean towards a scalable solution. MifOS is a rapidly maturing platform used in high load, concurrent environments already. Scalability questions are bound to come up. Cheers, Dion On Nov 16, 2007 2:44 PM, Keith Pierce <[EMAIL PROTECTED]> wrote: > The one-connection-per-http-session is certainly not scalable, but my > question is, how scalable does the application need to be? At one end of the > usage spectrum, application instances that only serve one user need not be > scalable. At the other end, an app server instance that potentially services > thousands of users.... It sounds like the GK scenario points to the latter. > > I'm pretty new to MifOS, and learning to navigate through project documents. > Are there any documents/emails that discuss the anticipated usage patterns > for MifOS and how those usage patterns translate into deployment strategies? > For example, one server per center, serving all branches? Any help to wend > my way through project notes would be greatly appreciated! > > Keith Pierce > > > > On Nov 15, 2007 2:23 PM, William Pietri <[EMAIL PROTECTED]> wrote: > > > > 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/ > > > > > ------------------------------------------------------------------------- > 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/ > ------------------------------------------------------------------------- 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/
