j dailey wrote: > I'm not your guy for patches, but I would suggest that this deserves a > P1 ranking and more discussion here - if I am right with my lense on > this, it is likely a fair amount of work to puzzle out what is > happening > and then to correct it. The current ranking is P2
<snip> > Some things I could note: > > Van was working on the persistence layer earlier > > > http://sourceforge.net/mailarchive/message.php?msg_id=46DF94D6.6080704%40gmail.com > > Quote: >> >" > As you have found, Mifos uses the idea of a Persistence layer. These >> >Persistence classes in Mifos are not yet implemented in as consistent > a > > >way as we would like, but the idea is that the creation, deletion, > > >update and lookup/retrieval of a given functional group of objects > > >should be encapsulated by methods defined on a Persistence class. For > > >reference, these Persistence classes are close to the "Repository" > > >design pattern as described by Fowler > > >(http://www.martinfowler.com/eaaCatalog/repository.html) and others. > The > > >goal is to make these Persistence classes follow the Repository > design > > >pattern-- there is still plenty of work to do in order to achieve > this goal." > # > > So, that's one area of major work in plumbing. But also, how are the > connection pools handled in Mifos? > > Looking at > > > http://sourceforge.net/mailarchive/message.php?msg_id=9DD845C1ED0D5D40B4B56DF5A4B1EB0EABB40C%40gfmail.gfusa.org > > I noted that Jim Kingdon was working on removing the JNDI dependency > with Terry Wong as late as October 2006. As I recall, we were able to remove the JNDI dependency in order to get a non-Web containerized version of Mifos up and drivable using command line tools for API development. I haven't fully kept up, but it looks like Van's Persistence classes have replaced the changes I'd added to DAO.java. > Finally, I note that I find only one mention of a "finally" block in > the mifos code (see > > > /mifosrepo/trunk/DevSpace/WorkSpace/src/org/mifos/framework/security/util/LoginFilter.java > > > finally{ > HibernateUtil.closeSession(); > } > > which is recommended as a general practice on the reading I have found > on this subject as follows: > > "When using connection pooling, it is important to remember that a > chunk of > bad code that neglects to return connections can starve the rest of the > application, causing it to eventually run out of connections and hang > (potentially failing nowhere near the actual problem). To test for > this, set the > maximum connections in your pool to a small number (as low as 1), and > use tools > like p6spy and IronTrack SQL (described above) to look for statements > that fail > to close. This problem can be avoided by always using a finally block > to close your connection..." Right, IF we are in fact using a connection pool, which I believe was not the case. Looking back on the thread James referenced earlier --> http://sourceforge.net/mailarchive/message.php?msg_id=9DD845C1ED0D5D40B4B56DF5A4B1EB0EABB40C%40gfmail.gfusa.org I must say I did not fully understanding the way the original persistence classes were handling Hibernate under the covers---there was a lot going on at the time, and we wanted to just get the JNDI issue solved, in parallel with getting iteration X done for GK---and given all the constraints, I think Jim and I left it to be an issue for re-examination/optimization/re-work when the time came. I think it's now fair to say that the time has come. If I understand the comments so far, this is not causing chronic severe pain, but we see some potential for a host of undesirable effects, including, but not limited to: 1. Data corruption 2. Interrupted work 3. Inability to scale to larger installations > I defer to those now on the list to comment - Sam? William? Terry? > Jim? Tom? Alija? I'm somewhat constrained on time these days, but I will take a look, and make an effort to report what I find to the list. If Sam, William, et. al.---anyone with some Hibernate/System Architecture chops would like to team up to take a crack at a fix, I'm game. Terry. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
