 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
 Posted: Thu Feb 08, 2007 3:37 am Post subject: Forcing Commit with a Managed Connection Pool in JBoss (J2EE |
 |
|
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 sad, 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 (AT) wwco (DOT) com |
|
| Back to top |
|
 |
Per Newgro
Guest
|
| Posted: Thu Feb 08, 2007 8:10 am Post subject: Re: Forcing Commit with a Managed Connection Pool in JBoss ( |
|
|
Hallo walt.stoneburner (AT) gmail (DOT) 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 |
|
| Back to top |
|
|
Guest
|
| Posted: Thu Feb 08, 2007 9:28 pm Post subject: Re: Forcing Commit with a Managed Connection Pool in JBoss ( |
|
|
On Feb 8, 2:34 am, Per Newgro <per.new...@gmx.ch> wrote:
| Quote: | 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 (AT) wwco (DOT) com |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
