You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Martin Kalén <mk...@apache.org> on 2004/08/11 13:02:01 UTC
Commons DBCP (was: Re: [OJB 1.1] Initial version check in)
Armin Waibel wrote:
> ** only supported by ConnectionFactoryDBCPImpl and deprecated. Should be
> removed.
>
> <!ATTLIST connection-pool
> connection-factory CDATA #IMPLIED
[...]
> **logAbandoned (true|false) #IMPLIED
> **removeAbandoned (true|false) #IMPLIED
> **removeAbandonedTimeout CDATA #IMPLIED
On the Jakarta Commons DBCP Wiki pages I found the following info (see
http://wiki.apache.org/jakarta-commons/DBCP):
"
Q: I see in the javadocs that AbandonedConnectionPool was deprecated (DBCP 1.1). What
replaced it?
A: The original reason for deprecation was the danger in reusing a abandoned connection
without knowing if it is safe to do so. There was a discussion about it in april. Some
people wanted to remove it completely.
I took a different approach. In 1.1 an abandoned connection will not be reused but closed
(and a new one created). The classes remained deprecated because I think the AbandonedPool
should move to the pool package (and made more generic/safe).
The abandoned connection feature on BasicDataSource will remain supported in one form or
another. I'm not using it on my tomcat production configurations but there are junit tests
to make sure everything works.
So if you are using the Abandoned* classes directly then it is possible you are affected
by a future refactoring (we will try to remain compatible if possible of course). If you
use BasicDataSource then you can be sure the feature will remain.
"
So when we implement the custom connection attributes in OJB1.1 we should probably also
upgrade to Commons DBCP 1.2.1 and try to use the BasicDataSource instead of AbandonedConfig.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Commons DBCP
Posted by Martin Kalén <mk...@apache.org>.
Thomas Dudziak wrote:
>> So when we implement the custom connection attributes in OJB1.1 we
>> should probably also upgrade to Commons DBCP 1.2.1 and try to use the
>> BasicDataSource instead of AbandonedConfig.
>
> Does this BasicDataSource derive from javax.sql.DataSource ? If so, it
> would perhaps best if we try to use pure DataSource's whenever possible.
> This would greatly simplify integration with other frameworks/libraries
> (e.g. Struts, Spring).
Bad wording from me. Rephrase; we should try to use BasicDataSource instead of (the
currently used) AbandonedConfig _in the Commons DBCP-specific connection factory
implementation code_.
This is unrelated to all other connection factories, and since OJB has a connection
factory API there is no risk that a single implementation narrows generic JDBC-classes
down to implementation-specific ones.
(I use "connection factory" terminology, although Armin's refactoring plans might change
this - however, the same concepts re DBCP apply.)
Cheers,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: bug when locking objects with references to proxies
Posted by Armin Waibel <ar...@apache.org>.
hi Georg,
seems similar to the changes I made. Will check in your patch asap.
regards,
Armin
Georg Schneider wrote:
> Hi Armin,
>
> Sorry, wrong subject in first post.
>
> This is how I did it.
>
> Cheers
> Georg
>
> --- src/java/org/apache/ojb/odmg/TransactionImpl.java 2004-08-12
> 13:55:36.000000000 +0200
> +++
> ../tmp/db-ojb-1.0.0/src/java/org/apache/ojb/odmg/TransactionImpl.java
> 2004-07-03 19:23:34.000000000 +0200
> @@ -871,12 +871,22 @@
> {
> if (!ProxyHelper.isProxy(obj) && (ref != null))
> {
> - ClassDescriptor objCld =
> this.getBroker().getClassDescriptor(obj.getClass());
> + Object refInstance = ProxyHelper.getRealObject(ref);
> + ClassDescriptor objCld =
> this.getBroker().getClassDescriptor(obj.getClass());
> FieldDescriptor[] objFkFields =
> rds.getForeignKeyFieldDescriptors(objCld);
>
> + // oma: refInstance might be null in case of dangling
> foreign keys.
> ValueContainer[] refPkValues;
> - ClassDescriptor refCld =
> this.getBroker().getClassDescriptor(ref.getClass());
> - refPkValues =
> getBroker().serviceBrokerHelper().getKeyValues(refCld, ref, false);
> + if (refInstance != null)
> + {
> + ClassDescriptor refCld =
> this.getBroker().getClassDescriptor(refInstance.getClass());
> + refPkValues =
> getBroker().serviceBrokerHelper().getKeyValues(refCld, refInstance, false);
> + }
> + else
> + {
> + refPkValues = new ValueContainer[objFkFields.length];
> + Arrays.fill(refPkValues, null);
> + }
>
> /**
> * MBAIRD:
>
>
> Brian McCallister wrote:
>
>> I seem to recall we upgraded to a newer DBCP a while back, had all
>> kinds of problems, so went back to older one. Would be good to make
>> work with new -- I agree.
>>
>> -Brian
>>
>> On Aug 11, 2004, at 7:12 AM, Thomas Dudziak wrote:
>>
>>> Martin Kalén wrote:
>>>
>>>> On the Jakarta Commons DBCP Wiki pages I found the following info
>>>> (see http://wiki.apache.org/jakarta-commons/DBCP):
>>>> "
>>>> Q: I see in the javadocs that AbandonedConnectionPool was deprecated
>>>> (DBCP 1.1). What replaced it?
>>>>
>>>> A: The original reason for deprecation was the danger in reusing a
>>>> abandoned connection without knowing if it is safe to do so. There
>>>> was a discussion about it in april. Some people wanted to remove it
>>>> completely.
>>>>
>>>> I took a different approach. In 1.1 an abandoned connection will not
>>>> be reused but closed (and a new one created). The classes remained
>>>> deprecated because I think the AbandonedPool should move to the pool
>>>> package (and made more generic/safe).
>>>>
>>>> The abandoned connection feature on BasicDataSource will remain
>>>> supported in one form or another. I'm not using it on my tomcat
>>>> production configurations but there are junit tests to make sure
>>>> everything works.
>>>>
>>>> So if you are using the Abandoned* classes directly then it is
>>>> possible you are affected by a future refactoring (we will try to
>>>> remain compatible if possible of course). If you use BasicDataSource
>>>> then you can be sure the feature will remain.
>>>> "
>>>>
>>>> So when we implement the custom connection attributes in OJB1.1 we
>>>> should probably also upgrade to Commons DBCP 1.2.1 and try to use
>>>> the BasicDataSource instead of AbandonedConfig.
>>>
>>>
>>>
>>> Does this BasicDataSource derive from javax.sql.DataSource ? If so,
>>> it would perhaps best if we try to use pure DataSource's whenever
>>> possible. This would greatly simplify integration with other
>>> frameworks/libraries (e.g. Struts, Spring).
>>>
>>> Tom
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: bug when locking objects with references to proxies
Posted by Georg Schneider <sc...@imp.univie.ac.at>.
Hi Armin,
Sorry, wrong subject in first post.
This is how I did it.
Cheers
Georg
--- src/java/org/apache/ojb/odmg/TransactionImpl.java 2004-08-12
13:55:36.000000000 +0200
+++
../tmp/db-ojb-1.0.0/src/java/org/apache/ojb/odmg/TransactionImpl.java
2004-07-03 19:23:34.000000000 +0200
@@ -871,12 +871,22 @@
{
if (!ProxyHelper.isProxy(obj) && (ref != null))
{
- ClassDescriptor objCld =
this.getBroker().getClassDescriptor(obj.getClass());
+ Object refInstance = ProxyHelper.getRealObject(ref);
+ ClassDescriptor objCld =
this.getBroker().getClassDescriptor(obj.getClass());
FieldDescriptor[] objFkFields =
rds.getForeignKeyFieldDescriptors(objCld);
+ // oma: refInstance might be null in case of dangling
foreign keys.
ValueContainer[] refPkValues;
- ClassDescriptor refCld =
this.getBroker().getClassDescriptor(ref.getClass());
- refPkValues =
getBroker().serviceBrokerHelper().getKeyValues(refCld, ref, false);
+ if (refInstance != null)
+ {
+ ClassDescriptor refCld =
this.getBroker().getClassDescriptor(refInstance.getClass());
+ refPkValues =
getBroker().serviceBrokerHelper().getKeyValues(refCld, refInstance, false);
+ }
+ else
+ {
+ refPkValues = new ValueContainer[objFkFields.length];
+ Arrays.fill(refPkValues, null);
+ }
/**
* MBAIRD:
Brian McCallister wrote:
> I seem to recall we upgraded to a newer DBCP a while back, had all kinds
> of problems, so went back to older one. Would be good to make work with
> new -- I agree.
>
> -Brian
>
> On Aug 11, 2004, at 7:12 AM, Thomas Dudziak wrote:
>
>> Martin Kalén wrote:
>>
>>> On the Jakarta Commons DBCP Wiki pages I found the following info
>>> (see http://wiki.apache.org/jakarta-commons/DBCP):
>>> "
>>> Q: I see in the javadocs that AbandonedConnectionPool was deprecated
>>> (DBCP 1.1). What replaced it?
>>>
>>> A: The original reason for deprecation was the danger in reusing a
>>> abandoned connection without knowing if it is safe to do so. There
>>> was a discussion about it in april. Some people wanted to remove it
>>> completely.
>>>
>>> I took a different approach. In 1.1 an abandoned connection will not
>>> be reused but closed (and a new one created). The classes remained
>>> deprecated because I think the AbandonedPool should move to the pool
>>> package (and made more generic/safe).
>>>
>>> The abandoned connection feature on BasicDataSource will remain
>>> supported in one form or another. I'm not using it on my tomcat
>>> production configurations but there are junit tests to make sure
>>> everything works.
>>>
>>> So if you are using the Abandoned* classes directly then it is
>>> possible you are affected by a future refactoring (we will try to
>>> remain compatible if possible of course). If you use BasicDataSource
>>> then you can be sure the feature will remain.
>>> "
>>>
>>> So when we implement the custom connection attributes in OJB1.1 we
>>> should probably also upgrade to Commons DBCP 1.2.1 and try to use the
>>> BasicDataSource instead of AbandonedConfig.
>>
>>
>> Does this BasicDataSource derive from javax.sql.DataSource ? If so, it
>> would perhaps best if we try to use pure DataSource's whenever
>> possible. This would greatly simplify integration with other
>> frameworks/libraries (e.g. Struts, Spring).
>>
>> Tom
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
--
============================================================================
Mag.Georg Schneider
Bioinformatics Group
Research Institute of Molecular Pathology (IMP)
Dr. Bohr Gasse 7
A-1030 Vienna
Austria
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Commons DBCP
Posted by Georg Schneider <sc...@imp.univie.ac.at>.
Hi Armin,
this is how I did it.
Cheers
Georg
--- src/java/org/apache/ojb/odmg/TransactionImpl.java 2004-08-12
13:55:36.000000000 +0200
+++
../tmp/db-ojb-1.0.0/src/java/org/apache/ojb/odmg/TransactionImpl.java
2004-07-03 19:23:34.000000000 +0200
@@ -871,12 +871,22 @@
{
if (!ProxyHelper.isProxy(obj) && (ref != null))
{
- ClassDescriptor objCld =
this.getBroker().getClassDescriptor(obj.getClass());
+ Object refInstance = ProxyHelper.getRealObject(ref);
+ ClassDescriptor objCld =
this.getBroker().getClassDescriptor(obj.getClass());
FieldDescriptor[] objFkFields =
rds.getForeignKeyFieldDescriptors(objCld);
+ // oma: refInstance might be null in case of dangling
foreign keys.
ValueContainer[] refPkValues;
- ClassDescriptor refCld =
this.getBroker().getClassDescriptor(ref.getClass());
- refPkValues =
getBroker().serviceBrokerHelper().getKeyValues(refCld, ref, false);
+ if (refInstance != null)
+ {
+ ClassDescriptor refCld =
this.getBroker().getClassDescriptor(refInstance.getClass());
+ refPkValues =
getBroker().serviceBrokerHelper().getKeyValues(refCld, refInstance, false);
+ }
+ else
+ {
+ refPkValues = new ValueContainer[objFkFields.length];
+ Arrays.fill(refPkValues, null);
+ }
/**
* MBAIRD:
Brian McCallister wrote:
> I seem to recall we upgraded to a newer DBCP a while back, had all kinds
> of problems, so went back to older one. Would be good to make work with
> new -- I agree.
>
> -Brian
>
> On Aug 11, 2004, at 7:12 AM, Thomas Dudziak wrote:
>
>> Martin Kalén wrote:
>>
>>> On the Jakarta Commons DBCP Wiki pages I found the following info
>>> (see http://wiki.apache.org/jakarta-commons/DBCP):
>>> "
>>> Q: I see in the javadocs that AbandonedConnectionPool was deprecated
>>> (DBCP 1.1). What replaced it?
>>>
>>> A: The original reason for deprecation was the danger in reusing a
>>> abandoned connection without knowing if it is safe to do so. There
>>> was a discussion about it in april. Some people wanted to remove it
>>> completely.
>>>
>>> I took a different approach. In 1.1 an abandoned connection will not
>>> be reused but closed (and a new one created). The classes remained
>>> deprecated because I think the AbandonedPool should move to the pool
>>> package (and made more generic/safe).
>>>
>>> The abandoned connection feature on BasicDataSource will remain
>>> supported in one form or another. I'm not using it on my tomcat
>>> production configurations but there are junit tests to make sure
>>> everything works.
>>>
>>> So if you are using the Abandoned* classes directly then it is
>>> possible you are affected by a future refactoring (we will try to
>>> remain compatible if possible of course). If you use BasicDataSource
>>> then you can be sure the feature will remain.
>>> "
>>>
>>> So when we implement the custom connection attributes in OJB1.1 we
>>> should probably also upgrade to Commons DBCP 1.2.1 and try to use the
>>> BasicDataSource instead of AbandonedConfig.
>>
>>
>> Does this BasicDataSource derive from javax.sql.DataSource ? If so, it
>> would perhaps best if we try to use pure DataSource's whenever
>> possible. This would greatly simplify integration with other
>> frameworks/libraries (e.g. Struts, Spring).
>>
>> Tom
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
--
============================================================================
Mag.Georg Schneider
Bioinformatics Group
Research Institute of Molecular Pathology (IMP)
Dr. Bohr Gasse 7
A-1030 Vienna
Austria
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Commons DBCP
Posted by Brian McCallister <mc...@forthillcompany.com>.
I seem to recall we upgraded to a newer DBCP a while back, had all
kinds of problems, so went back to older one. Would be good to make
work with new -- I agree.
-Brian
On Aug 11, 2004, at 7:12 AM, Thomas Dudziak wrote:
> Martin Kalén wrote:
>
>> On the Jakarta Commons DBCP Wiki pages I found the following info
>> (see http://wiki.apache.org/jakarta-commons/DBCP):
>> "
>> Q: I see in the javadocs that AbandonedConnectionPool was deprecated
>> (DBCP 1.1). What replaced it?
>>
>> A: The original reason for deprecation was the danger in reusing a
>> abandoned connection without knowing if it is safe to do so. There
>> was a discussion about it in april. Some people wanted to remove it
>> completely.
>>
>> I took a different approach. In 1.1 an abandoned connection will not
>> be reused but closed (and a new one created). The classes remained
>> deprecated because I think the AbandonedPool should move to the pool
>> package (and made more generic/safe).
>>
>> The abandoned connection feature on BasicDataSource will remain
>> supported in one form or another. I'm not using it on my tomcat
>> production configurations but there are junit tests to make sure
>> everything works.
>>
>> So if you are using the Abandoned* classes directly then it is
>> possible you are affected by a future refactoring (we will try to
>> remain compatible if possible of course). If you use BasicDataSource
>> then you can be sure the feature will remain.
>> "
>>
>> So when we implement the custom connection attributes in OJB1.1 we
>> should probably also upgrade to Commons DBCP 1.2.1 and try to use the
>> BasicDataSource instead of AbandonedConfig.
>
> Does this BasicDataSource derive from javax.sql.DataSource ? If so, it
> would perhaps best if we try to use pure DataSource's whenever
> possible. This would greatly simplify integration with other
> frameworks/libraries (e.g. Struts, Spring).
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Commons DBCP
Posted by Thomas Dudziak <to...@first.fhg.de>.
Martin Kalén wrote:
> On the Jakarta Commons DBCP Wiki pages I found the following info (see
> http://wiki.apache.org/jakarta-commons/DBCP):
> "
> Q: I see in the javadocs that AbandonedConnectionPool was deprecated
> (DBCP 1.1). What replaced it?
>
> A: The original reason for deprecation was the danger in reusing a
> abandoned connection without knowing if it is safe to do so. There was
> a discussion about it in april. Some people wanted to remove it
> completely.
>
> I took a different approach. In 1.1 an abandoned connection will not
> be reused but closed (and a new one created). The classes remained
> deprecated because I think the AbandonedPool should move to the pool
> package (and made more generic/safe).
>
> The abandoned connection feature on BasicDataSource will remain
> supported in one form or another. I'm not using it on my tomcat
> production configurations but there are junit tests to make sure
> everything works.
>
> So if you are using the Abandoned* classes directly then it is
> possible you are affected by a future refactoring (we will try to
> remain compatible if possible of course). If you use BasicDataSource
> then you can be sure the feature will remain.
> "
>
> So when we implement the custom connection attributes in OJB1.1 we
> should probably also upgrade to Commons DBCP 1.2.1 and try to use the
> BasicDataSource instead of AbandonedConfig.
Does this BasicDataSource derive from javax.sql.DataSource ? If so, it
would perhaps best if we try to use pure DataSource's whenever possible.
This would greatly simplify integration with other frameworks/libraries
(e.g. Struts, Spring).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org