<div class="ii gt" id=":cn">Hello again, </div>
<div class="ii gt"> </div>
<div class="ii gt">On June 1, I sent a post out reporting a connection release issue with jBPM 3.2.3. There are no replies to this post. </div>
<div class="ii gt"> </div>
<div class="ii gt">Today, we realized this same issue is causing databse connections to leak in the JobExecutorThread (which runs async jobs and timers). </div>
<div class="ii gt"> </div>
<div class="ii gt">We worked around the initial problem quite easily with a few lines of code (see below). But resolving it in JobExecutorThread would require a lot more hackery. Before we hack away, I wanted to again see if anyone has come across this issue, and if so how you might have addressed it. </div>
<div class="ii gt"> </div>
<div class="ii gt">Hope to hear from you soon, </div>
<div class="ii gt"> </div>
<div class="ii gt">Brian </div>
<div class="ii gt"> </div>
<div class="ii gt">== Original post begins below == </div>
<div class="ii gt"> </div>
<div class="ii gt"> </div>
<div class="ii gt">Hello <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">jbpm</font></span> gurus,<br><br>We're seeing database connection leakage with <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">jBPM</font></span> 3.2.3 in our unit tests.<br>
<br>Specifically, this JUnit test fails, showing that connections are not<br>being released back to the connection pool:<br> int connectionsBorrowed = datasource.getBorrowedConnectionsCount();<br> // getBorrowedConnectionsCount() is a method on<br>
Oracle's UCP connection pooling<br> JbpmConfiguration config =<br>JbpmConfiguration.parseResource("<span class="il"><font style="BACKGROUND-COLOR: #3d85c6">jbpm</font></span>.cfg.xml");<br> JbpmContext <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">context</font></span> = config.createJbpmContext();<br>
<span class="il"><font style="BACKGROUND-COLOR: #3d85c6">context</font></span>.getSession();<br> assertEquals(connectionsBorrowed + 1,<br>datasource.getBorrowedConnectionsCount()); // passes<br> <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">context</font></span>.<span class="il"><font style="BACKGROUND-COLOR: #3d85c6">close</font></span>();<br>
assertEquals("db connection leakage", connectionsBorrowed, datasource<br> .getBorrowedConnectionsCount()); // fails<br><br>Here's the snippet of our <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">jbpm</font></span>.cfg.xml file that configures the<br>
persistence service for our test cases:<br> <service name="persistence"><br> <factory><br> <bean class="org.<span class="il"><font style="BACKGROUND-COLOR: #3d85c6">jbpm</font></span>.persistence.db.DbPersistenceServiceFactory"><br>
<field name="dataSourceJndiName"><string value="jdbc/bpsmDS"/> </field><br> <field name="isCurrentSessionEnabled"><false /></field><br>
<field name="isTransactionEnabled"><true /></field><br> </bean><br> </factory><br> </service><br><br>The issue might be related to the DbPersistenceService methods<br>
getConnection(boolean) and getSession(). getConnection(boolean)<br>initially sets mustConnectionBeClosed to true when we get a connection<br>out of the datasource, but getSession() then sets this flag back to<br>false.<br>
<br>As a workaround, we wrote the following custom method for closing a<br>JbpmContext):<br> public void <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">close</font></span>(JbpmContext <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">context</font></span>) {<br>
Connection connection = <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">context</font></span>.getConnection();<br> <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">context</font></span>.<span class="il"><font style="BACKGROUND-COLOR: #3d85c6">close</font></span>();<br>
try {<br> connection.<span class="il"><font style="BACKGROUND-COLOR: #3d85c6">close</font></span>(); // release connection back to pool<br> } catch (SQLException e) {<br> throw new IllegalStateException(e);<br>
}<br> }<br><br>In our non-test environment (where we use JTA transactions), we are<br>not experiencing connection leakage, so my guess is that the container<br>(WebSphere) has been closing the connection automatically at the end<br>
of the transaction.<br><br>Questions:<br> 1. Have we misconfigured <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">jBPM</font></span> or is there some other reason why we're<br>leaking database connections in our test environment?<br>
2. Is it ok if we start explicitly calling connection.<span class="il"><font style="BACKGROUND-COLOR: #3d85c6">close</font></span>() in the<br>container? For example, will doing so prevent the container from<br>committing it's transaction (I'm guessing not)? So far our testing<br>
shows no problems whether or not we explicitly call <span class="il"><font style="BACKGROUND-COLOR: #3d85c6">close</font></span>() in a JTA<br>environment, but I wanted to make sure about this....<br><br><br>Looking forward to your thoughts on the above questions,<br>
<font color="#888888"><br>Brian Westrich<br><a href="mailto:bw@mcwest.com"><font color="#0065cc">bw@mcwest.com</font></a><br></font></div>