Java Beans - Forcing Commit with a Managed Connection Pool in JBoss (J2EE)

Author

Forcing Commit with a Managed Connection Pool in JBoss (J2EE)

walt.stoneburner@gmail.com

2007-02-07, 7:03 pm

In the normal world of JDBC, dealing with a transaction is trivial -
get a connection, set the auto commit to false, do your stuff, call
commit() if you're happy, call rollback() if you're

, and close.

Connection Pools are supposed to avoid the overhead of repeated
connections to the database, and I was mistakenly under the assumption
that little else changed. JBoss allows you to get a context, and from
the context a connection pool, to which you use it, and upon closing,
the connection is returned to the pool. However, there are several
oddities I think I need explained by someone who's walked over this
ground before.

I'm aware that with JBoss's managed connection pool, one cannot call
setAutoCommit() -- fine, it default to false, which is what I want
anyhow.

But I can't seem to call commit() or rollback() either. Is there some
other call I'm supposed to be using?

And the really weird part... even after I perform a close(), the
transaction doesn't seem to commit immediately.

Unfortunately, Googling for JBoss managed connection pools doesn't
get much useful information.

Can got any clues or can point me at an online reference about JBoss's
behavior for managed connections?

thx.
-wls@wwco.com

Per Newgro

2007-02-08, 4:04 am

Hallo walt.stoneburner@gmail.com,

You talking about beans? If so you don't need (afaik) any connection pool.
Get the connection from the datasource you defined within a
UserTransaction. You can get the transaction by the SessionContext. And
with this you can commit or rollback.

Connection pooling is a container concept!!!

But maybe i misunderstood the problem

Cheers
Per

walt.stoneburner@gmail.com

2007-02-08, 7:04 pm

On Feb 8, 2:34 am, Per Newgro <per.new...@gmx.ch> wrote:
> You talking about beans? ... Connection pooling is a container concept!!!
> But maybe i misunderstood the problem

Per, thanks for your response -- it has just challenged me to think
that perhaps my whole understanding is drastically broken. As such,
I'll toss out a few assumptions; please, anyone, feel free to correct
me.

Beans, as I understand them, are units of code inside a EJB
container. I'm roughly aware there is a particular type of bean used
for persistence of data. It was my understanding that in order to do
this, correctly, certain conventions needed to be followed. And, in
the ideal case, something like Hibernate is a fantastic solution.

However, in my current case, we have little control over the actual
database -- it's got all kinds of wacky joins, views, stored
procedures, constraints, and is frequently being modified by other
external systems... there's custom stuff Hibernate just couldn't know
about; consequently, we actually don't have objects we're trying to
persist, but rather are just trying to get in, execute some SQL, and
get back out in the shortest period of time.

So, am I using a bean to do the persisting for me... no. Is the code
thread inside of a bean when I'm trying to access the database...
yes.

Paralleling plain old JDBC, my thought was literally to get the
context, get the datasource, and obtain a connection like this:
Context ic = new InitialContext();
DataSource ds = ( DataSource ) ic.lookup( datasource_name );
Connection conn = ds.getConnection();

And, this seems to work. However, conn.commit() doesn't work. It
feels like I'm not really getting a connection, but a transaction.
"But why do the above in the first place?" you may be thinking. The
overhead of straight JDBC was slow, if JBoss has a connection pool
available that I can borrow from, the speed increase is well worth
it. Additionally, my SQL statement is to call a stored procedure, not
persist an object in memory.

What has me thinking, based on your response is the UserTransaction
and SessionContext. I haven't run across those yet. And your
mentioning that connection pooling is a container concept adds
additional doubt that perhaps I'm doing something very wrong, perhaps
touching JBoss internals that have no business playing with.

Does that help clarify the details?

-Walt Stoneburner
wls@wwco.com

Sponsored Links