Using JBoss's JDBC Managed Connection Pools

[wls]

Hello - need some to point me in the right direction.

I have some JDBC code that was working perfectly until I changed it to use JBoss's managed connection pools. I'm hoping someone can point me to an authoritative reference source online instructing proper usage of the connection pools.

Before I was getting a connection, setting setAutoCommit() to false, doing a number of statements, calling commit(), and then closing the connection -- worked great.

Now I'm getting a connection, (can't touch auto commit though it seems to be false), doing a number of statements, (can't call commit() or rollback() -why?), and then closing the connection -- which doesn't seem to do the commit. In fact, shortly after close(), I can go look with a db admin tool and the tables show no evidence of any INSERT statements happening. ...wait a while, and perhaps it might.

It's acting like close() releases to the pool, but the commit() may be done later. This is not good news for other pieces of code expecting something to now be in the database.

Clearly I'm missing something -- what's the right group to ask such questions of, or, optionally, what's the right piece of documentation I should be looking at?

-Walt Stoneburner
[e-mail]

[wls]

More detail and a code example of the JDBC/EE issue can be found here:

http://groups.google.com/group/comp.lang.java.databases/browse_thread/thread/02281cdf714c39be/

[wls]

Ok, so here's what I'm learning so far -- and perhaps my question was nonsensical.

In JDBC you get a connection, to which you can have database transactions.

When you start talking about Transactions in terms of JBoss, these are NOT database transactions, but unit of work transactions.

If your bean happens to represent some piece of business logic, then it's easy to see how invoking a method on that bean starts a transaction, and when the method exits, the transaction is done. Complexity arises when beans start using other beans, because you have to decide if it's part of the same transaction, a separate transaction, and if the transactions have any dependency on one another.

JBoss can persist your bean using Container Managed Persistence (CMP), or your bean can persist itself using Bean Managed Persistence (BMP). In each case, it uses a database connection pool ...and so far things make sense.

My problem is that my bean is stateless with no data to persist. It merely enters a very long look when told to do so. My thought was that I, as a bean writer, had the exact same access to the database connection pool and could use it to serve my whims, wholly independent of object persistence.

Two things are complicating that. One, I can't seem to get the JBoss connection pool to let me have a connection which allows me to do commits. Two, all of my processing seems to be happening in the context of some magic all-encompassing wrapper transaction, so even when I do twiddle with the database, using the connection pool, it won't commit until the invoking method exits. And for what I want to do, that isn't helpful at all.

Is there a way, perhaps with some annotation or something, to indicate that no transaction is desired? And is there a way to grab a raw connection from the connection pool?