The short answer: it needs to scale. GK has 44 branches, plus users at the head office. More branches will be added in the coming months. Also-as a side note-most users use the system at the same time of day, and many of them run db-intensive activities like report running. (for an overview, see http://mifos.org/developers/how-mifos-is-used)
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith Pierce Sent: Friday, November 16, 2007 6:15 PM To: Developer Subject: Re: [Mifos-developer] Fw: Mifos production issues and likelyhibernateconnection pooling 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/
