Missing releaseAllResource in ConnectionFactoryDBCPImpl
When i request a ConnectionManager.releaseAllResource in DBCPConnectionManager , The connection are not release ,and if i change the JdbcConnectionDescriptor to a new database the old connection are used again . The method releaseAllResource is not defined on the DBCPConnectionManager .The Map(poolMap) which is containing the datasources is never cleaned . And the connection for a same pbkey ( even if the ConnectionDescriptor change ) are always the same . B.R Thierry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDO : Unable to update object with references
I know I have already posted about this but it is very annoying and I
have been stuck to this problem for one week...
I create an instance of Company. I make it persistent : ok, my DB get it
perfectly.
I create a Division for my instance of Company. I make it persistent and
everything goes well too.
I begin a transaction. I retrieve my instance of Company. I change its
name and I commit and at this point I get this :
[JDO] DEBUG: OjbStoreManager.flush: company.business.Division{1}, P_NEW
[JDO] DEBUG: OjbStoreManager.insert
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: SQLException
during the execution of the insert (for a company.business.Division):
Invalid argument value, message from server: Duplicate entry '1' for
key 1
That is to say, OJB does not understand that this Division which is
referenced by the modified Company only need to be updated and not
inserted.
How can I change it ?
Any clue, advice, feeling, prayer welcome :)
--
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: SQL exceptions when using DList
Hi Scott, Weaver, Scott wrote: Why you need to specify DListImpl as collection class? I found this approach in the mailing list archive. If I don't specify it, OJB uses the RemovalAwareCollection instead. I would think, since I am using ODMG, this would be a better approach. The real reason for this is that I have use cases that are failing. Example unit test case: 1:n automatic update use case: A contains a collection of B. B has a reference back to its parent A. Calling A.addB(B) sets B's reference to A. Create new A. Create new B. Add B to A. Make A persistent. A and B successfully persisted to the DB. Clear the OJB cache Retrieve A (using PB) Start Tx (ODMG) Lock A for writing (ODMG) Create a new B2. Add B2 to A. Commit Tx. Clear Cache. Retrieve A (using PB) Assert(A count Bs == 2) FAIL. B2 was never persisted. ODMG's Persistence by reachability should have persisted B2, should it not? I'm not a ODMG expert, but I guess you are right. I will add some new tests to reproduce your problem. I made some quick test and it seems the problem is the reference (of B) back to its parent. When adding objects without an reference back to parent all works as expected. Will try to fix this ASAP. regars, Armin I thought that using DList might fix this. Regards, ** | Scott T Weaver | | [EMAIL PROTECTED]| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | ** -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 9:37 AM To: OJB Users List Subject: Re: SQL exceptions when using DList Hi Scott, Weaver, Scott wrote: Hi All, I have never used the ODMG specific collection classes before. That being said, I just started using DList in some of my mappings. Example: collection-descriptor name=portlets element-class- ref=org.apache.jetspeed.om.common.portlet.PortletDefinitionCo mposite collection-class=org.apache.ojb.odmg.collections.DListImpl inverse-foreignkey field-ref=appId/ /collection-descriptor However, when I do specify the DListImpl, I get this error when updating to the DB: Could not obtain next object: Can't build new sequence: Table not found: OJB_HL_SEQ in statement [SELECT A0.VERSION,A0.GRAB_SIZE,A0.MAX_KEY,A0.FIELDNAME,A0.TABLENAME FROM OJB_HL_SEQ A0 WHERE A0.TABLENAME LIKE 'SEQ_OJB_DLIST' ] The DListImpl class request on creation time and for each entry an ID from the SequenceManager (DListImpl_2 a new implementation try to avoid this overhead) and it seems you don't have created the tables used by DListImpl. Why you need to specify DListImpl as collection class? regards, Armin Thanks, ** | Scott T Weaver | | [EMAIL PROTECTED]| | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apologies
I apologies to all of you and especially to Gopi Nandamuri
for the mail i posted a few days ago on this mailing list.
My intention was not to offend Gopi and in fact i
completely misunderstood his questions. In the future,
i will pay close attention, before replying to a mail,
to be sure to have really understood the meaning and to
be able to give something consistent as a reply.
As a good will and amendment gesture i want to propose the following
code of a PersistentField that i wrote to solve a problem i had
with nested fields. I think that the problem is not restrained to me.
The problem arise when using nested objects that can be nulled.
Actually, when ojb reads the first field of a nested object that is
null, an instance is created to continue the recursive walk through
the nested objects, even if the given value to set for the attribute
is null. So i needed to make two modifications for the process to work.
* first i had overriden the 'set' method of the AbstractPersistentField
class to early test if the value will not be set. The added test is
borrowed from the PersistentFieldDirectAccessImpl but is performed
before having created an instance of the nested object.
public void set(Object targetObject, Object value) throws
MetadataException
{
if (isNestedField())
{
if (value != null || !getField().getType().isPrimitive())
{
setNestedObject(targetObject, fieldName, value);
}
}
else
{
doSet(targetObject, value);
}
}
* the second modification i did is needed because the test on the 'set'
method
works only for primitive types. But if we store a Date for example in a
nested
object, it will be nevertheless created. But the test can not extend
the test
made earlier, because if we nested objects could have non-null default
values
for certain fields. So i overrided the 'setNestedObject' method to
perform
the test so that when realizing that the nested object is null, there
is no need
to create one to put a null value in the field.
When the added test 'if (attrib != null || value != null)' is true
the instanciation and setting of the attribute is skipped.
protected void setNestedObject(Object obj, String fieldName, Object
value)
{
int index = fieldName.indexOf(PATH_TOKEN);
if (index = 0)
{
String name = fieldName.substring(0, index);
PersistentField pField =
createInternPersistentField(ProxyHelper.getRealClass(obj), name);
Object attrib = pField.get(ProxyHelper.getRealObject(obj));
if (attrib != null || value != null)
{
if (attrib == null)
{
...
}
String nestedName = fieldName.substring(index +
PATH_TOKEN.length());
setNestedObject(attrib, nestedName, value);
}
}
else
{
PersistentField pField =
createInternPersistentField(ProxyHelper.getRealClass(obj), fieldName);
pField.set(ProxyHelper.getRealObject(obj), value);
}
}
Best regards,
Guillaume Nodet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apologies
Hi Guillaume,
Guillaume Nodet wrote:
I apologies to all of you and especially to Gopi Nandamuri
for the mail i posted a few days ago on this mailing list.
My intention was not to offend Gopi and in fact i
completely misunderstood his questions. In the future,
i will pay close attention, before replying to a mail,
to be sure to have really understood the meaning and to
be able to give something consistent as a reply.
We all make mistakes (except most managers) ;-)
As a good will and amendment gesture i want to propose the following
code of a PersistentField that i wrote to solve a problem i had
with nested fields.
Thanks for this contribution and detailed description (I understand the
problem ;-)). I will add a test for this problem and adopt your fix
ASAP. Thanks!
regards,
Armin
I think that the problem is not restrained to me.
The problem arise when using nested objects that can be nulled.
Actually, when ojb reads the first field of a nested object that is
null, an instance is created to continue the recursive walk through
the nested objects, even if the given value to set for the attribute
is null. So i needed to make two modifications for the process to work.
* first i had overriden the 'set' method of the AbstractPersistentField
class to early test if the value will not be set. The added test is
borrowed from the PersistentFieldDirectAccessImpl but is performed
before having created an instance of the nested object.
public void set(Object targetObject, Object value) throws
MetadataException
{
if (isNestedField())
{
if (value != null || !getField().getType().isPrimitive())
{
setNestedObject(targetObject, fieldName, value);
}
}
else
{
doSet(targetObject, value);
}
}
* the second modification i did is needed because the test on the 'set'
method
works only for primitive types. But if we store a Date for example in a
nested
object, it will be nevertheless created. But the test can not extend
the test
made earlier, because if we nested objects could have non-null default
values
for certain fields. So i overrided the 'setNestedObject' method to
perform
the test so that when realizing that the nested object is null, there
is no need
to create one to put a null value in the field.
When the added test 'if (attrib != null || value != null)' is true
the instanciation and setting of the attribute is skipped.
protected void setNestedObject(Object obj, String fieldName, Object
value)
{
int index = fieldName.indexOf(PATH_TOKEN);
if (index = 0)
{
String name = fieldName.substring(0, index);
PersistentField pField =
createInternPersistentField(ProxyHelper.getRealClass(obj), name);
Object attrib = pField.get(ProxyHelper.getRealObject(obj));
if (attrib != null || value != null)
{
if (attrib == null)
{
...
}
String nestedName = fieldName.substring(index +
PATH_TOKEN.length());
setNestedObject(attrib, nestedName, value);
}
}
else
{
PersistentField pField =
createInternPersistentField(ProxyHelper.getRealClass(obj), fieldName);
pField.set(ProxyHelper.getRealObject(obj), value);
}
}
Best regards,
Guillaume Nodet
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Orion App-server
Hi, Thomas Mahler wrote: forwarded to the ojb-user list. Thomas Original Message Date: Thu, 22 Jan 2004 09:17:13 -0800 From: He, Paul (EDS) [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Thomas, I am just starting to use OJB recently. Oracle application server (Orion server) is our choice. I wonder if you have some examples I deploy an OJB application on Orion server. I really get confused on the configuration. Also, do I need to write a customized startup object as the instruction for Weblogic or Jboss? Thank you so much. OJB was shipped with some session bean examples. In the documentation was a detailed description for deployment on jboss. Instead a jboss specific sar-file/dir you can direct deploy the sample beans or setup an .ear file. All configuration for Orion is the same as for JBoss, except JTATransactionManagerClass= org.apache.ojb.otm.transaction.factory.OrionTransactionManagerFactory To make the OJB api's accessible via JNDI, you need to bind api's main classes to JNDI. - *org.apache.ojb.broker.core.PersistenceBrokerFactoryFactory* for PB-api. Make method PersistenceBrokerFactoryFactory.instance() accessible. For jboss we doing this via org.apache.ojb.jboss.PBFactory mbean. - *org.apache.ojb.odmg.OJBJ2EE_2* for ODMG-api. Make OJBJ2EE_2.getInstance() accessible. For jboss we doing this via org.apache.ojb.jboss.ODMGFactory mbean For a simple test it is possible to use this classes directly in your sample beans (without JNDI lookup). I attached latest version of deployment doc (with some additional hints). regards, Armin Paul He A Representative of HSDD PLANO, TX Phone:+1-972-604-8855 mailto: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
