You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/07/04 03:21:36 UTC
[DBCP] Managed Connection support
I just posted a patch JIRA which adds support for container managed
connections to DBCP. In an environment where you have an accessible
transaction manger such as Tomcat (when installed), Geronimo or
OpenEJB, this patch allows adds support for pooling managed
connections to an XA or non-XA data base.
There are many libraries that use DBCP for non-managed environments,
but when additional resources such as a JMS provider are added to the
mix, they have to replace DBCP with something else. If you search
google for XA and DBCP, you will loads of painful direction on how to
replace DBCP with something else. I personally want to use DBCP in
Tomcat with ActiveMQ.
Anyways, enough with motivation....
To use the new code, you need access to a TranactionManager (this
code just creates a new Geronimo one).
transactionManager = new TransactionManagerImpl();
Then you either create an XADataSource and
DataSourceXAConectionFactory or as this code does, create a normal
DBCP ConnectionFactory and wrap it with a LocalXAConectionFactory
Properties properties = new Properties();
properties.setProperty("user", "username");
properties.setProperty("password", "password");
ConnectionFactory connectionFactory = new
DriverConnectionFactory(
new TesterDriver(),
"jdbc:apache:commons:testdriver", properties);
// wrap it with a LocalXAConnectionFactory
XAConnectionFactory xaConnectionFactory = new
LocalXAConnectionFactory(
transactionManager,
connectionFactory);
Now you create a pool as normal (full reuse here).
pool = new GenericObjectPool();
pool.setMaxActive(getMaxActive());
pool.setMaxWait(getMaxWait());
// create the pool object factory
PoolableConnectionFactory factory = new
PoolableConnectionFactory(
xaConnectionFactory,
pool,
null,
"SELECT DUMMY FROM DUAL",
true,
true);
pool.setFactory(factory);
Finally, you create a special ManagedDataSource using the pool above
and the special TransactionRegistry object obtained from the
XAConnectionFactory.
ds = new ManagedDataSource(pool,
xaConnectionFactory.getTransactionRegistry());
ds.setAccessToUnderlyingConnectionAllowed(true);
That's it. The data source and connections work as normal until you
start a transaction using the TransactionManager. When you use a
connection while the transaction is active, the connection is
enlisted in the transaction. When the transaction is complete, the
connection is committed (or rolledback) and the connection returns to
normal.
Most of the new code extends existing classes or uses existing
classes without modification. The key to this reuse is the
TransactionRegistry abstraction which maintains a map from the
Connection to the XAResource for that connection. The XAResource is
needed to enlist a connection in a transaction. The
TransactionRegistry and associated TransationContext class
encapsulate all interactions with the TransactionManager leaving the
Connection implementation relatively simple (making reuse easier).
For now the code is contained in the org.apache.commons.dbcp.managed
package, but I would suspect we may want to spread it out amongst the
existing packages instead of creating a feature specific package.
I'm also not sure what additional interfaces people may want such as
equivalents of the BasicDataSource or BasicDataSourceFactory.
The code has tests and has javadoc, but it needs real world testing
and some real docs. I'm going try hooking it into OpenEJB and
running it's massive test suite with a couple of opensource DBs.
Anyways, I hope you all like it and accept the patch. I'm around to
help with changes or whatever. I also ran into a few bugs while
working on this that are already reported in JIRA (like the close
bugs) and am willing to help with those also.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: [DBCP] Managed Connection support
Posted by Phil Steitz <ph...@gmail.com>.
On 7/6/07, Dain Sundstrom <da...@iq80.com> wrote:
> On Jul 5, 2007, at 7:13 AM, Phil Steitz wrote:
>
> > Thanks, Dain. I applied the patch.
> >
> > I also patched the m1 and ant builds to work. The Ant now fails with
> > JDK 1.3, but unless someone screams loudly soon, we have moved the
> > minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so
> > this is not an issue.
>
> Sweet! That was very fast.
>
> > <snip/>
> >>
> >> For now the code is contained in the org.apache.commons.dbcp.managed
> >> package, but I would suspect we may want to spread it out amongst the
> >> existing packages instead of creating a feature specific package.
> >> I'm also not sure what additional interfaces people may want such as
> >> equivalents of the BasicDataSource or BasicDataSourceFactory.
> >>
> > I am ambivalent on the merging into existing packages, but we should
> > talk about this.
>
> We can figure that out as we get close to a release. If the thing
> isn't fully tested by then we could just mark the whole package as
> experimental.
>
Thats what I was thinking, so good to leave as is for now.
> >> The code has tests and has javadoc, but it needs real world testing
> >> and some real docs. I'm going try hooking it into OpenEJB and
> >> running it's massive test suite with a couple of opensource DBs.
> >>
> >> Anyways, I hope you all like it and accept the patch. I'm around to
> >> help with changes or whatever. I also ran into a few bugs while
> >> working on this that are already reported in JIRA (like the close
> >> bugs) and am willing to help with those also.
> >>
> > That would be greatly appreciated. We really need [dbcp] and [pool]
> > volunteers. Given that you are an ASF committer, all you have to do
> > is ask to get commons karma and you are certainly welcome to do that
> > :)
>
> Excellent, I definitely like access, so I can fix any bugs in the
> code directly.
>
Looks like there's a little beaurocracy to go through here, but pls
keep the patches coming for now.
> > In [dbcp] 1.3, we can fix the close semantics and other things that
> > involve semantic changes. All suggestions and patches are welcome.
>
> I'll take a look at it when I get back in town next week.
Thanks in advance. You will find that some of these bugs relate to
[pool] and fixes need to either be mindful of current pool impl - most
importantly the fact that the core of pool is an idle object linked
list and there is no guard to protect against the same object
appearing multiple times in the list, which will happen if it is
returned twice, resulting in serious badness for dbcp - or we need to
do something with pool to keep the changes safe. There is an
alternative pool impl in the compositepool package in pool head, but
the current plan is to push out one more patch release of pool and
have dbcp 1.3 continue to use the GenericObjectPool. See roadmap
discussion here:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg94027.html
Comments welcome!
Since POOL-97 is causing app server issues, it would be great to get
some feedback on the proposed fix there and then bundle up a pool
1.3.1 patch release.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] Managed Connection support
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 5, 2007, at 7:13 AM, Phil Steitz wrote:
> Thanks, Dain. I applied the patch.
>
> I also patched the m1 and ant builds to work. The Ant now fails with
> JDK 1.3, but unless someone screams loudly soon, we have moved the
> minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so
> this is not an issue.
Sweet! That was very fast.
> <snip/>
>>
>> For now the code is contained in the org.apache.commons.dbcp.managed
>> package, but I would suspect we may want to spread it out amongst the
>> existing packages instead of creating a feature specific package.
>> I'm also not sure what additional interfaces people may want such as
>> equivalents of the BasicDataSource or BasicDataSourceFactory.
>>
> I am ambivalent on the merging into existing packages, but we should
> talk about this.
We can figure that out as we get close to a release. If the thing
isn't fully tested by then we could just mark the whole package as
experimental.
>> The code has tests and has javadoc, but it needs real world testing
>> and some real docs. I'm going try hooking it into OpenEJB and
>> running it's massive test suite with a couple of opensource DBs.
>>
>> Anyways, I hope you all like it and accept the patch. I'm around to
>> help with changes or whatever. I also ran into a few bugs while
>> working on this that are already reported in JIRA (like the close
>> bugs) and am willing to help with those also.
>>
> That would be greatly appreciated. We really need [dbcp] and [pool]
> volunteers. Given that you are an ASF committer, all you have to do
> is ask to get commons karma and you are certainly welcome to do that
> :)
Excellent, I definitely like access, so I can fix any bugs in the
code directly.
> In [dbcp] 1.3, we can fix the close semantics and other things that
> involve semantic changes. All suggestions and patches are welcome.
I'll take a look at it when I get back in town next week.
Thanks again,
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] Managed Connection support
Posted by Phil Steitz <ph...@gmail.com>.
>
> I just posted a patch JIRA which adds support for container managed
> connections to DBCP. In an environment where you have an accessible
> transaction manger such as Tomcat (when installed), Geronimo or
> OpenEJB, this patch allows adds support for pooling managed
> connections to an XA or non-XA data base.
>
> There are many libraries that use DBCP for non-managed environments,
> but when additional resources such as a JMS provider are added to the
> mix, they have to replace DBCP with something else. If you search
> google for XA and DBCP, you will loads of painful direction on how to
> replace DBCP with something else. I personally want to use DBCP in
> Tomcat with ActiveMQ.
>
Thanks, Dain. I applied the patch.
I also patched the m1 and ant builds to work. The Ant now fails with
JDK 1.3, but unless someone screams loudly soon, we have moved the
minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so
this is not an issue.
<snip/>
>
> For now the code is contained in the org.apache.commons.dbcp.managed
> package, but I would suspect we may want to spread it out amongst the
> existing packages instead of creating a feature specific package.
> I'm also not sure what additional interfaces people may want such as
> equivalents of the BasicDataSource or BasicDataSourceFactory.
>
I am ambivalent on the merging into existing packages, but we should
talk about this.
> The code has tests and has javadoc, but it needs real world testing
> and some real docs. I'm going try hooking it into OpenEJB and
> running it's massive test suite with a couple of opensource DBs.
>
> Anyways, I hope you all like it and accept the patch. I'm around to
> help with changes or whatever. I also ran into a few bugs while
> working on this that are already reported in JIRA (like the close
> bugs) and am willing to help with those also.
>
That would be greatly appreciated. We really need [dbcp] and [pool]
volunteers. Given that you are an ASF committer, all you have to do
is ask to get commons karma and you are certainly welcome to do that
:)
In [dbcp] 1.3, we can fix the close semantics and other things that
involve semantic changes. All suggestions and patches are welcome.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Fwd: [DBCP] Managed Connection support
Posted by Niall Pemberton <ni...@gmail.com>.
Forwarding to Commons Dev...
---------- Forwarded message ----------
From: Dain Sundstrom <da...@iq80.com>
Date: Jul 4, 2007 2:21 AM
Subject: [DBCP] Managed Connection support
To: Jakarta General List <ge...@jakarta.apache.org>
I just posted a patch JIRA which adds support for container managed
connections to DBCP. In an environment where you have an accessible
transaction manger such as Tomcat (when installed), Geronimo or
OpenEJB, this patch allows adds support for pooling managed
connections to an XA or non-XA data base.
There are many libraries that use DBCP for non-managed environments,
but when additional resources such as a JMS provider are added to the
mix, they have to replace DBCP with something else. If you search
google for XA and DBCP, you will loads of painful direction on how to
replace DBCP with something else. I personally want to use DBCP in
Tomcat with ActiveMQ.
Anyways, enough with motivation....
To use the new code, you need access to a TranactionManager (this
code just creates a new Geronimo one).
transactionManager = new TransactionManagerImpl();
Then you either create an XADataSource and
DataSourceXAConectionFactory or as this code does, create a normal
DBCP ConnectionFactory and wrap it with a LocalXAConectionFactory
Properties properties = new Properties();
properties.setProperty("user", "username");
properties.setProperty("password", "password");
ConnectionFactory connectionFactory = new
DriverConnectionFactory(
new TesterDriver(),
"jdbc:apache:commons:testdriver", properties);
// wrap it with a LocalXAConnectionFactory
XAConnectionFactory xaConnectionFactory = new
LocalXAConnectionFactory(
transactionManager,
connectionFactory);
Now you create a pool as normal (full reuse here).
pool = new GenericObjectPool();
pool.setMaxActive(getMaxActive());
pool.setMaxWait(getMaxWait());
// create the pool object factory
PoolableConnectionFactory factory = new
PoolableConnectionFactory(
xaConnectionFactory,
pool,
null,
"SELECT DUMMY FROM DUAL",
true,
true);
pool.setFactory(factory);
Finally, you create a special ManagedDataSource using the pool above
and the special TransactionRegistry object obtained from the
XAConnectionFactory.
ds = new ManagedDataSource(pool,
xaConnectionFactory.getTransactionRegistry());
ds.setAccessToUnderlyingConnectionAllowed(true);
That's it. The data source and connections work as normal until you
start a transaction using the TransactionManager. When you use a
connection while the transaction is active, the connection is
enlisted in the transaction. When the transaction is complete, the
connection is committed (or rolledback) and the connection returns to
normal.
Most of the new code extends existing classes or uses existing
classes without modification. The key to this reuse is the
TransactionRegistry abstraction which maintains a map from the
Connection to the XAResource for that connection. The XAResource is
needed to enlist a connection in a transaction. The
TransactionRegistry and associated TransationContext class
encapsulate all interactions with the TransactionManager leaving the
Connection implementation relatively simple (making reuse easier).
For now the code is contained in the org.apache.commons.dbcp.managed
package, but I would suspect we may want to spread it out amongst the
existing packages instead of creating a feature specific package.
I'm also not sure what additional interfaces people may want such as
equivalents of the BasicDataSource or BasicDataSourceFactory.
The code has tests and has javadoc, but it needs real world testing
and some real docs. I'm going try hooking it into OpenEJB and
running it's massive test suite with a couple of opensource DBs.
Anyways, I hope you all like it and accept the patch. I'm around to
help with changes or whatever. I also ran into a few bugs while
working on this that are already reported in JIRA (like the close
bugs) and am willing to help with those also.
-dain
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [DBCP] Managed Connection support
Posted by Henning Schmiedehausen <he...@apache.org>.
Hi Dain,
thanks a lot for this input. Can you please resend your message to the
commons-dev list located at commons-dev@jakarta.apache.org ?
To add some a little bit confusion: The commons have just decided to
become a top-level project in their own right, so the development list
will move to dev@commons.apache.org at some point in the near future.
Still, it would be great to follow up on your suggestions;
TransactionSupport would be a real benefit to DBCP.
Best regards
Henning
On Tue, 2007-07-03 at 18:21 -0700, Dain Sundstrom wrote:
> I just posted a patch JIRA which adds support for container managed
> connections to DBCP. In an environment where you have an accessible
> transaction manger such as Tomcat (when installed), Geronimo or
> OpenEJB, this patch allows adds support for pooling managed
> connections to an XA or non-XA data base.
>
> There are many libraries that use DBCP for non-managed environments,
> but when additional resources such as a JMS provider are added to the
> mix, they have to replace DBCP with something else. If you search
> google for XA and DBCP, you will loads of painful direction on how to
> replace DBCP with something else. I personally want to use DBCP in
> Tomcat with ActiveMQ.
>
> Anyways, enough with motivation....
>
> To use the new code, you need access to a TranactionManager (this
> code just creates a new Geronimo one).
>
> transactionManager = new TransactionManagerImpl();
>
> Then you either create an XADataSource and
> DataSourceXAConectionFactory or as this code does, create a normal
> DBCP ConnectionFactory and wrap it with a LocalXAConectionFactory
>
> Properties properties = new Properties();
> properties.setProperty("user", "username");
> properties.setProperty("password", "password");
> ConnectionFactory connectionFactory = new
> DriverConnectionFactory(
> new TesterDriver(),
> "jdbc:apache:commons:testdriver", properties);
>
> // wrap it with a LocalXAConnectionFactory
> XAConnectionFactory xaConnectionFactory = new
> LocalXAConnectionFactory(
> transactionManager,
> connectionFactory);
>
>
> Now you create a pool as normal (full reuse here).
>
> pool = new GenericObjectPool();
> pool.setMaxActive(getMaxActive());
> pool.setMaxWait(getMaxWait());
>
> // create the pool object factory
> PoolableConnectionFactory factory = new
> PoolableConnectionFactory(
> xaConnectionFactory,
> pool,
> null,
> "SELECT DUMMY FROM DUAL",
> true,
> true);
> pool.setFactory(factory);
>
>
> Finally, you create a special ManagedDataSource using the pool above
> and the special TransactionRegistry object obtained from the
> XAConnectionFactory.
>
> ds = new ManagedDataSource(pool,
> xaConnectionFactory.getTransactionRegistry());
> ds.setAccessToUnderlyingConnectionAllowed(true);
>
>
> That's it. The data source and connections work as normal until you
> start a transaction using the TransactionManager. When you use a
> connection while the transaction is active, the connection is
> enlisted in the transaction. When the transaction is complete, the
> connection is committed (or rolledback) and the connection returns to
> normal.
>
> Most of the new code extends existing classes or uses existing
> classes without modification. The key to this reuse is the
> TransactionRegistry abstraction which maintains a map from the
> Connection to the XAResource for that connection. The XAResource is
> needed to enlist a connection in a transaction. The
> TransactionRegistry and associated TransationContext class
> encapsulate all interactions with the TransactionManager leaving the
> Connection implementation relatively simple (making reuse easier).
>
> For now the code is contained in the org.apache.commons.dbcp.managed
> package, but I would suspect we may want to spread it out amongst the
> existing packages instead of creating a feature specific package.
> I'm also not sure what additional interfaces people may want such as
> equivalents of the BasicDataSource or BasicDataSourceFactory.
>
> The code has tests and has javadoc, but it needs real world testing
> and some real docs. I'm going try hooking it into OpenEJB and
> running it's massive test suite with a couple of opensource DBs.
>
> Anyways, I hope you all like it and accept the patch. I'm around to
> help with changes or whatever. I also ran into a few bugs while
> working on this that are already reported in JIRA (like the close
> bugs) and am willing to help with those also.
>
> -dain
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org