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 Thomas Dudziak <to...@first.fhg.de> on 2004/08/11 13:12:50 UTC
Re: Commons DBCP
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
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