The problem is still there with the current cvs build.
It's Minerva pools that cause the problem.
A class ObjectPool has getObject() method. This method calls XAConnectionFactory to prepare a pooled connection. In case this method doesn't succeed to enlist resource with transaction (because transaction has already been marked for rollback) it throws RuntimeException.
getObject method does not catch the exception which leaves a pool record marked as inUse although the method doesn't return an object so it can't be released from outside.
Here's the code:
ObjectPool.java:
public Object getObject() {
...
...
while(true) {
Iterator it = objects.values().iterator();
while(it.hasNext()) {
ObjectRecord rec = (ObjectRecord)it.next();
if(!rec.isInUse()) {
Object ob=null;
try {
rec.setInUse(true);
ob = rec.getObject();
result = factory.prepareObject(ob); // RuntimeException occurs here if resource can't be enlisted with transaction
if(result != ob) rec.setClientObject(result);
if(result instanceof PooledObject)
((PooledObject)result).addPoolEventListener(this);
log("Pool "+this+" gave out pooled object: "+result);
return result;
// CHANGE HERE: -->
// REMOVE THIS LINE
} catch(ConcurrentModificationException e) {}
// REPLACE IT WITH THIS:
} catch(Exception ex) {
releaseObject(ob);
// rec.setInUse(false); // or would it be good enough to say it like this?
if(ex instanceof RuntimeException && !(ex instanceof ConcurrentModificationException)) throw (RuntimeException)ex;
}
// <-- CHANGE
}
}
...
...
}
That's not all. We need to do some exception handling in XAConnectionFactory also:
public Object prepareObject(Object pooledObject) {
XAConnection con = (XAConnection)pooledObject;
con.addConnectionEventListener(listener);
Transaction trans = null;
try {
if(tm.getStatus() != Status.STATUS_NO_TRANSACTION) {
trans = tm.getTransaction();
XAResource res = con.getXAResource();
trans.enlistResource(res);
rms.put(con, res);
if(log != null) log.println("Resource '"+res+"' enlisted for '"+con+"'.");
} else {
if(log != null) log.println("No transaction right now.");
}
} catch(Exception e) {
Logger.exception(e);
// CHANGE HERE: -->
// ADD THIS LINE
con.removeConnectionEventListener(listener);
// <-- CHANGE
throw new RuntimeException("Unable to register with TransactionManager: "+e);
}
if(con instanceof XAConnectionImpl) {
((XAConnectionImpl)con).setTransactionListener(transListener);
if(trans != null) {
wrapperTx.put(con, trans); // For JDBC 1/2 wrappers, remember which
wrapperTx.put(trans, con); // connection goes with a given transaction
}
}
return con;
}
This seems to do the trick. Now, I have no real knowledge of how transaction processing should go in here.
My bug hunt was strictly operational - 'make connection leaks go away'. And this fix does achieve that.
So looks like the problem can be fixed inside the minerva package. I've noticed this has been moved to its own jar.
I think it's best mr. Mulder :) fixes this.
Marko.
> -----Original Message-----
> From: Aaron Mulder [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 09, 2001 10:17 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] FW: [jBoss-User] LOCKING-WAITING
> (TRANSACTION)
>
>
> On Fri, 9 Feb 2001, marc fleury wrote:
> > RE: [jBoss-User] LOCKING-WAITING (TRANSACTION)Hey was this
> fixed in the new
> > version? I know we worked with the exception problems...
>
> The new version of what? Not fixed in the new version
> of Minerva;
> Minerva is never informed when a bean has a runtime
> exception. It would
> have to be in an exception handler somewhere to return the
> connection to
> Minerva.
> However, the connection(s) would be returned to the pool
> eventually if you have garbage collection enabled in Minerva
> - but you'd
> have to run it pretty often if this happens a lot, so we
> should try to fix
> it in the CMP interceptor or whatever which originally checks out the
> connection.
>
> Aaron
>
