Duplicate key error when inserting a new record
Hi! I use OJB-1.0rc5 with a mysql (innodb) as backend. When we insert concurrently objects that have two 1:n-relations into the same table pos_receipt from e.g. 4 clients, we get the following duplicate-primary-key-message: 14.06.2004 09:40:47 ch.eugster.pos.db.DBResult log SCHWERWIEGEND: 23000: Duplicate key or integrity constraint violation, message from server: Duplicate entry '1822' for key 1 ojb increments the primarykey (Long). Has anybody an idea, what I am doing wrong? Thank your! Christian the repository connection-descriptor looks like this: --- ... jdbc-connection-descriptor jcd-alias=standard default-connection=false platform=mySQL jdbc-level=3.0 driver=com.mysql.jdbc.Driver protocol=jdbc subprotocol=mysql dbalias=//salespoint:3306/colibri username=colibri password=colibri batch-mode=false useAutoCommit=2 eager-release=false ignoreAutoCommitExceptions=false connection-pool maxActive=5 validationQuery= / sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl attribute attribute-name=grabSize attribute-value=5 / /sequence-manager /jdbc-connection-descriptor ... --- the class-descriptors look like this: XXX pos_receipt class-descriptor class=ch.eugster.pos.db.Receipt table=pos_receipt isolation-level=read-uncommitted accept-locks=true refresh=false field-descriptor name=id column=id jdbc-type=BIGINT primarykey=true indexed=true access=readwrite autoincrement=true nullable=true locking=false update-lock=true default-fetch=false / field-descriptor name=timestamp column=timestamp jdbc-type=TIMESTAMP primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=number column=number indexed=true jdbc-type=VARCHAR length=25 primarykey=false nullable=true autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=transactionId column=transaction_id jdbc-type=BIGINT primarykey=false indexed=true access=readwrite autoincrement=false nullable=false locking=false update-lock=true default-fetch=false / field-descriptor name=bookingId column=booking_id jdbc-type=BIGINT primarykey=false indexed=true access=readwrite autoincrement=false nullable=false locking=false update-lock=true default-fetch=false / field-descriptor name=salespointId column=salespoint_id jdbc-type=BIGINT primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=userId column=user_id jdbc-type=BIGINT primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=foreignCurrencyId column=foreign_currency_id jdbc-type=BIGINT primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=status column=status jdbc-type=INTEGER primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=settlement column=settlement jdbc-type=BIGINT primarykey=false indexed=true nullable=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=amount column=amount jdbc-type=DOUBLE primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / reference-descriptor name=salespoint class-ref=ch.eugster.pos.db.Salespoint proxy=false refresh=false auto-retrieve=true auto-update=false auto-delete=false otm-dependent=false foreignkey field-ref=salespointId / /reference-descriptor reference-descriptor name=user class-ref=ch.eugster.pos.db.User proxy=false refresh=false auto-retrieve=true auto-update=false auto-delete=false otm-dependent=false foreignkey field-ref=userId / /reference-descriptor reference-descriptor name=foreignCurrency class-ref=ch.eugster.pos.db.ForeignCurrency proxy=false refresh=false auto-retrieve=true auto-update=false auto-delete=false otm-dependent=false foreignkey field-ref=foreignCurrencyId / /reference-descriptor collection-descriptor name=positions element-class-ref=ch.eugster.pos.db.Position auto-retrieve=true auto-update=true auto-delete=true sort=ASC proxy=false refresh=false otm-dependent=false orderby name=id sort=ASC / inverse-foreignkey field-ref=receiptId / /collection-descriptor collection-descriptor name=payments element-class-ref=ch.eugster.pos.db.Payment auto-retrieve=true auto-update=true auto-delete=true sort=ASC proxy=false refresh=false
Three level inheritance problem - Null data from the mostly nested table
Hi I try to realize three level of inheritance in OJB. My Class C extends Class B extends Class A each data are stored in separate tables (Table A, Table B, Table C) . I've implemented it. Inserts work fine. Inheritance is OK, all data are stored in tables.All references are OK. I have problems with quering objects. I try to get all C Class object. In each object I can't get access to data which are stored in A Table (they are null). But when I try to list A Class Objects, their data are complete. I noticed very strange thing. When I try to list object in this order, both methods works fine (Collection returned by method getCClassObject is OK, all object,s data are complete): ... Collection AClassObjects=getAClassObjects(); //getting A Class objects Collection CClassObjects=getCClassObjects(); //getting C Class objects ... But my problems start when I try to invoke only one method: .. Collection CClassObjects=getCClassObjects(); //getting C Class object .. Object of CClassObjects collection haven't data stored in A table (the mostly nested)... I have to use the other solution... but it doesn't work Please help me ... Best regards mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RC7 contains JBoss TX fix? was Re: [ANN] OJB 1.0rc7 Released
Hi Guido, Guido Beutler wrote: Hi, does RC7 contains the JBoss transaction fix Armin build for me? The problem was to return the JDBC Connection earlyer to avoid returning unknown connection exceptions yep! It also include another fix: PersistenceBrokerFactorySyncImpl.java now always use the same PB instance (PBF.createPer calls) within the same jta-transaction. regards, Armin best regards, Guido - 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: Cascading anonymous keys
Hi Brian,
Brian Latimer wrote:
Armin,
I have tried my code with rc7 and I still have the problem I described.
Looking at the test case you have written, it seems to produce the
results I would like. That is, your code does not return null objects
for objects that should be retrieved via anonymous foreign keys
contained within nested objects.
The only major difference I have seen between your test case and my code
thus far is that you have a reference to a Person within the
PersonDetail.
This shouldn't be a problem. In the test I set auto-retrieve to false
for this reference. But I will try to run the test without the reference
to be sure.
public static class PersonDetail implements PersonDetailIF
{
Integer id;
String profile;
Person person; // - I don't have
this reference
GenderIF gender;
...
I tried adding a reference like you have but ended up with the same
results that I had without such a reference.
My code looks very much like your test case, but I still get nulls on my
nested objects if I use anonymous keys and turn proxies off.
While I think you have shown that the problems must be with my code
somewhere, I'm certainly baffled as to what might be wrong.
I am using PersistentFieldIntrospectorImpl and most of my properties are
private, do you suppose that would cause a problem on nested objects?
I run PrimaryKeyForeignKeyTest.java with PersistentFieldIntrospectorImpl
but all tests pass, thus it seems that this isn't the problem.
A difference between your test and PrimaryKeyForeignKeyTest is that you
using another SequenceManager to generate the PK values (assume you are
using SequenceManagerNativeImpl, because PK was set to 'readonly'). I
don't know if this could be a problem, maybe you try to run your test
with another SequenceManager (e.g. SequenceManagerInMemoryImpl and non
Identity column for PK).
regards,
Armin
Thank you very much for looking into this for me.
Brian
At 08:58 AM 06/12/2004, Armin Waibel wrote:
Hi Brian,
I tried to reproduce your problem (with latest from CVS) without
success. A new test case was added to test suite
([db-ojb]/src/test/org/...) called PrimaryKeyForeignKeyTest.java, the
mapping is declared in repository_junit_reference.
Please have a look at this test, does it reproduce your problem?
regards,
Armin
-
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: [ANN] OJB 1.0rc7 Released
Hi Steve, Steve Clark wrote: Brian - odmg-api: Creation of m:n relation only works when Brian objects created step by step (or use PB-api as workaround), Brian persist a whole object graph doesn't work. On delete of Brian collection objects from a m:n relation objects will be Brian deleted from the indirection table and (unexpected Brian behaviour) from the referenced table too. me Also unsure about the deletion piece: Does this mean that me auto-delete=link doesn't work with ODMG any more (it's been me working ok in RC6)? Armin hmm, at all times the top-level api need the default values Armin for auto-xxx settings: Armin auto-retrieve true Armin auto-update false Armin auto-delete false Armin But except for auto-delete on 1:1 relation, 'false' is Armin equals with 'link'. Oops. I shouldn't have brought in auto-delete. It sounds from the release notes like there's a new behavior where removing an object from an m:n relation removes the object from the db, as well. Is this only with RemovalAwareCollection (in which case I think it's expected?), or is this with all collection classes (in which case I think it's a new behavior and very seriously broken)? ooh, seems I made a mistake in the test cases repository I don't specified a non-removeaware collection-class. Maybe I should read the docs before I start writing the next test cases ;-). Will check this and remove the entry in the release notes if I have success. Steve, thank you very much! regards, Armin thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] OJB 1.0rc7 Released
Can someone please clarify exactly what property changed in OJB.properties as mentioned below? Thanks. - OJB.properties file has changed, don't forget to replace on update! One new property to set in managed environments. --- Brian McCallister [EMAIL PROTECTED] wrote: The OJB team would like to announce the release of Apache Object/Relational Bridge (OJB) 1.0rc7. This release will hopefully be the final release candidate before version 1.0. If no major problems are discovered, OJB 1.0 will be released in one week. DOWNLOADS http://db.apache.org/builds/ojb/ CHANGES: - New Apache Forrest generated web site. - OJB.properties file has changed, don't forget to replace on update! One new property to set in managed environments. - Logging settings have moved to separate OJB-logging.properties file - Logging initialization is now decoupled form OJB initialization; this is described in the new reference guide for logging - It is no longer necessary to provide an empty repository.xml file when starting without repository and connection descriptors - rename/move internal package org.apache.ojb.odmg.transaction to org.apache.ojb.broker.transaction.tm In managed environments each (top-level) API use transaction manager access, thus the TM related classes are moved to the PB kernel and OJB.properties entries change. - Base class for ODMG api access within non- or managed environments is now org.apache.ojb.odmg.OJB. The used org.odmg.Implementation interface implementation is specified in OJB.properties. - ConnectionManager is more strict on CM.releaseConnection() method calls. Now an exception is thrown when CM is in a local transaction status when try to release the connection. The local tx status of ConnectionManager and PersistenceBroker implementation is now decoupled, useful in managed environments allows to close the connection without change the PB tx-state. - the indirection handler (for reference proxies), and the list and set proxy classes can now be configured in the OJB.properties file - new CollectionProxy interface introduced to allow the ODMG api to make use of alternate collection proxy implementations. KNOWN ISSUES: - odmg-api: It is not possible to exchange objects in 1:n references. - odmg-api: Creation of m:n relation only works when objects created step by step (or use PB-api as workaround), persist a whole object graph doesn't work. On delete of collection objects from a m:n relation objects will be deleted from the indirection table and (unexpected behaviour) from the referenced table too. - A count on ReportQueries containing groupBy does not deliver a correct result. - Batch handling doesn't work properly with optimistic locking. - ReportQueries should not be used with columns referencing Classes with extents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : OJB and RMI
A thread problem ? Does your problem occurs the first call or only next one ? Jean-Baptiste BRIAUD SYSDEO www.sysdeo.com software engineer www.eclipsetotale.com -Message d'origine- De : Bradford Pielech [mailto:[EMAIL PROTECTED] Envoyé : mardi 15 juin 2004 16:34 À : OJB Users List Objet : OJB and RMI Hello all: I am having running into a problem. I have an RMI server which intends to make calls to MySQL, using PersistencBroker. It fails when I call: PersistenceBroker pbroker = PersistenceBrokerFactory.defaultPersistenceBroker(); with: - [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object --- If I remove RMI from the equation, everything works fine, i.e. the PersistenceBroker calls succeed. With RMI, the Remote Server gets a NoClassDefFoundError For the PersistenceBrokerFactory. Is there possibly anything in the OJB configuration that might affect this environment? Has anyone else been able to get OJB to work in this scenario? Thanks, Brad - 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 : OJB and RMI
The problem occurs the very first time we call anything to do with PersistenceBroker. Another thing of note is that the RMI server and OJB / MySQL libraries are all on the same machine. Brad At 04:36 PM 6/15/2004 +0200, you wrote: A thread problem ? Does your problem occurs the first call or only next one ? Jean-Baptiste BRIAUD SYSDEO www.sysdeo.com software engineer www.eclipsetotale.com -Message d'origine- De : Bradford Pielech [mailto:[EMAIL PROTECTED] Envoyé : mardi 15 juin 2004 16:34 À : OJB Users List Objet : OJB and RMI Hello all: I am having running into a problem. I have an RMI server which intends to make calls to MySQL, using PersistencBroker. It fails when I call: PersistenceBroker pbroker = PersistenceBrokerFactory.defaultPersistenceBroker(); with: - [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object --- If I remove RMI from the equation, everything works fine, i.e. the PersistenceBroker calls succeed. With RMI, the Remote Server gets a NoClassDefFoundError For the PersistenceBrokerFactory. Is there possibly anything in the OJB configuration that might affect this environment? Has anyone else been able to get OJB to work in this scenario? Thanks, Brad - 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]
Pb on jdo.getCol and Delete
All,
I retrieve a jdo collection with the jdo.getCol method. I'm using dynamic
proxy. OJB RC7 same pb in RC6
I'm using an iterator on this col and delete each object retrieve.
Later (not all time but 50% time) I commit and I have an Unmaterialized
proxy error !!
It seems that after a while (undefined time) the proxy is unmaterialized and
the commit could not order to delete the object ..
Database db = impl.getDatabase(product);
Collection col = jdo.getCol();
Iterator iter = col.iterator();
While (iter.hasNext()) {
Jdoxx myxx = iter.next();
db.deletePersistent(myxx);
}
blablablablablablabla.later on
commit();
What wrong in my logic ???
Any help would be appreciated! Tx !!
Re: RE : OJB and RMI
Bradford Pielech wrote: The problem occurs the very first time we call anything to do with PersistenceBroker. Another thing of note is that the RMI server and OJB / MySQL libraries are all on the same machine. This seems to be a classloader problem, perhaps the thread's context classloader is the RMI classloader (which does not find OJB's classes) ? If you're using a fresh version of OJB (rc7 or CVS), then you can put breakpoints into the org.apache.ojb.broker.util.ClassHelper#getClass and #newInstance methods to see which classloader is used (the PersistenceBrokerFactory is present otherwise you'd get a different error, so this occurs within OJB). Using the ClassHelper class, you can also define which classloader OJB uses. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] OJB 1.0rc7 Released
Armin Waibel writes: Armin ooh, seems I made a mistake in the test cases repository I Armin don't specified a non-removeaware collection-class. Maybe Armin I should read the docs before I start writing the next test Armin cases ;-). Not to beat a dead horse, but I think this is yet another very clear demonstration that the default behavior is counterintuitive. It really seems that it would be better for non-RemovalAwareCollection to be the default, with RemovalAwareCollection available as an option for those who want that behavior. -- Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] OJB 1.0rc7 Released
Steve Clark wrote: Armin Waibel writes: Armin ooh, seems I made a mistake in the test cases repository I Armin don't specified a non-removeaware collection-class. Maybe Armin I should read the docs before I start writing the next test Armin cases ;-). Not to beat a dead horse, but I think this is yet another very clear demonstration that the default behavior is counterintuitive. It really seems that it would be better for non-RemovalAwareCollection to be the default, with RemovalAwareCollection available as an option for those who want that behavior. I agree with you, but some time ago the argument for using RemovalAwareCollections as default collection-class was to make PB-api delete collection objects behaviour similar to the ODMG-api. I don't know when we change collection-class, but originally non-RemovalAwareCollection was used as default one. If most OJB user vote for an rollback to non-RAC, we can switch back again (hopefully the last time ;-)). As an alternative I will have a look in source and try to make default collection-class pluggable via OJB.properties file. If it will be possible, we can satisfy both strategies. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] OJB 1.0rc7 Released
Hi Gary, Gary wrote: Can someone please clarify exactly what property changed in OJB.properties as mentioned below? Thanks. OJB.properties file new properties: -ListProxyClass -IndirectionHandlerClass -SetProxyClass -RowReaderDefaultClass odmg specific -ImplementationClass The logging properties moved to a separate file. regards, Armin - OJB.properties file has changed, don't forget to replace on update! One new property to set in managed environments. --- Brian McCallister [EMAIL PROTECTED] wrote: The OJB team would like to announce the release of Apache Object/Relational Bridge (OJB) 1.0rc7. This release will hopefully be the final release candidate before version 1.0. If no major problems are discovered, OJB 1.0 will be released in one week. DOWNLOADS http://db.apache.org/builds/ojb/ CHANGES: - New Apache Forrest generated web site. - OJB.properties file has changed, don't forget to replace on update! One new property to set in managed environments. - Logging settings have moved to separate OJB-logging.properties file - Logging initialization is now decoupled form OJB initialization; this is described in the new reference guide for logging - It is no longer necessary to provide an empty repository.xml file when starting without repository and connection descriptors - rename/move internal package org.apache.ojb.odmg.transaction to org.apache.ojb.broker.transaction.tm In managed environments each (top-level) API use transaction manager access, thus the TM related classes are moved to the PB kernel and OJB.properties entries change. - Base class for ODMG api access within non- or managed environments is now org.apache.ojb.odmg.OJB. The used org.odmg.Implementation interface implementation is specified in OJB.properties. - ConnectionManager is more strict on CM.releaseConnection() method calls. Now an exception is thrown when CM is in a local transaction status when try to release the connection. The local tx status of ConnectionManager and PersistenceBroker implementation is now decoupled, useful in managed environments allows to close the connection without change the PB tx-state. - the indirection handler (for reference proxies), and the list and set proxy classes can now be configured in the OJB.properties file - new CollectionProxy interface introduced to allow the ODMG api to make use of alternate collection proxy implementations. KNOWN ISSUES: - odmg-api: It is not possible to exchange objects in 1:n references. - odmg-api: Creation of m:n relation only works when objects created step by step (or use PB-api as workaround), persist a whole object graph doesn't work. On delete of collection objects from a m:n relation objects will be deleted from the indirection table and (unexpected behaviour) from the referenced table too. - A count on ReportQueries containing groupBy does not deliver a correct result. - Batch handling doesn't work properly with optimistic locking. - ReportQueries should not be used with columns referencing Classes with extents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - 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: Three level inheritance problem - Null data from the mostly nested table
Hi Mariusz, did you try latest release (rc7)? Jakob fix a problem with inheritance between rc6 and rc7. regards, Armin Mariusz Wjcik wrote: Hi I try to realize three level of inheritance in OJB. My Class C extends Class B extends Class A each data are stored in separate tables (Table A, Table B, Table C) . I've implemented it. Inserts work fine. Inheritance is OK, all data are stored in tables.All references are OK. I have problems with quering objects. I try to get all C Class object. In each object I can't get access to data which are stored in A Table (they are null). But when I try to list A Class Objects, their data are complete. I noticed very strange thing. When I try to list object in this order, both methods works fine (Collection returned by method getCClassObject is OK, all object,s data are complete): ... Collection AClassObjects=getAClassObjects(); //getting A Class objects Collection CClassObjects=getCClassObjects(); //getting C Class objects ... But my problems start when I try to invoke only one method: .. Collection CClassObjects=getCClassObjects(); //getting C Class object .. Object of CClassObjects collection haven't data stored in A table (the mostly nested)... I have to use the other solution... but it doesn't work Please help me ... Best regards mario - 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: RE : OJB and RMI
Tom: Thanks for the pointer, but it still isn't working. Here is some sample code inside the RMI server that illustrates the failure: String s = RMIClassLoader.getClassAnnotation(PersistenceBrokerFactory.class); ClassLoader cl = RMIClassLoader.getClassLoader(s); org.apache.ojb.broker.util.ClassHelper.setClassLoader(cl); PersistenceBroker pbroker = PersistenceBrokerFactory.defaultPersistenceBroker(); System.out.println(PBroker: + pbroker.toString()); This produces the error: --- [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object -- Any other ideas? Brad At 04:54 PM 6/15/2004 +0200, you wrote: Bradford Pielech wrote: The problem occurs the very first time we call anything to do with PersistenceBroker. Another thing of note is that the RMI server and OJB / MySQL libraries are all on the same machine. This seems to be a classloader problem, perhaps the thread's context classloader is the RMI classloader (which does not find OJB's classes) ? If you're using a fresh version of OJB (rc7 or CVS), then you can put breakpoints into the org.apache.ojb.broker.util.ClassHelper#getClass and #newInstance methods to see which classloader is used (the PersistenceBrokerFactory is present otherwise you'd get a different error, so this occurs within OJB). Using the ClassHelper class, you can also define which classloader OJB uses. Tom - 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: RE : OJB and RMI
Bradford Pielech wrote: Tom: Thanks for the pointer, but it still isn't working. Here is some sample code inside the RMI server that illustrates the failure: String s = RMIClassLoader.getClassAnnotation(PersistenceBrokerFactory.class); ClassLoader cl = RMIClassLoader.getClassLoader(s); org.apache.ojb.broker.util.ClassHelper.setClassLoader(cl); PersistenceBroker pbroker = PersistenceBrokerFactory.defaultPersistenceBroker(); System.out.println(PBroker: + pbroker.toString()); This produces the error: --- [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object -- Any other ideas? Hmm, I'm by no means an RMI expert (at least in environments where performance is not an issue, I'd rather use XML-RPC), but I wonder whether the RMI classloader is correctly initialized to find OJB classes, or whether OJB is correctly configured. Have a look into your OJB.properties file to see what the persistence broker factory class is that would used (property PersistenceBrokerFactoryClass). If this property is not defined, then the above error results (there is no default value for this property). If it is defined, then either the OJB.properties file could not be loaded (you should see this in the same log where the above error message was output), or the class could not be loaded. In the first case, the OJB.properties file could probably not loaded (you can set its path manually using the system property OJB.properties prior to using *any* OJB class). In the latter case, please try to load the class directly using the RMI classloader: Class.forName(classname, true, cl); and see what happens then. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicate key error when inserting a new record
Hi Christian, hmm difficult to say what's going wrong. I can't find metadata for 'ch.eugster.pos.db.DBResult' class or what does this entry mean? regards, Armin Christian Eugster wrote: Hi! I use OJB-1.0rc5 with a mysql (innodb) as backend. When we insert concurrently objects that have two 1:n-relations into the same table pos_receipt from e.g. 4 clients, we get the following duplicate-primary-key-message: 14.06.2004 09:40:47 ch.eugster.pos.db.DBResult log SCHWERWIEGEND: 23000: Duplicate key or integrity constraint violation, message from server: Duplicate entry '1822' for key 1 ojb increments the primarykey (Long). Has anybody an idea, what I am doing wrong? Thank your! Christian the repository connection-descriptor looks like this: --- ... jdbc-connection-descriptor jcd-alias=standard default-connection=false platform=mySQL jdbc-level=3.0 driver=com.mysql.jdbc.Driver protocol=jdbc subprotocol=mysql dbalias=//salespoint:3306/colibri username=colibri password=colibri batch-mode=false useAutoCommit=2 eager-release=false ignoreAutoCommitExceptions=false connection-pool maxActive=5 validationQuery= / sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl attribute attribute-name=grabSize attribute-value=5 / /sequence-manager /jdbc-connection-descriptor ... --- the class-descriptors look like this: XXX pos_receipt class-descriptor class=ch.eugster.pos.db.Receipt table=pos_receipt isolation-level=read-uncommitted accept-locks=true refresh=false field-descriptor name=id column=id jdbc-type=BIGINT primarykey=true indexed=true access=readwrite autoincrement=true nullable=true locking=false update-lock=true default-fetch=false / field-descriptor name=timestamp column=timestamp jdbc-type=TIMESTAMP primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=number column=number indexed=true jdbc-type=VARCHAR length=25 primarykey=false nullable=true autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=transactionId column=transaction_id jdbc-type=BIGINT primarykey=false indexed=true access=readwrite autoincrement=false nullable=false locking=false update-lock=true default-fetch=false / field-descriptor name=bookingId column=booking_id jdbc-type=BIGINT primarykey=false indexed=true access=readwrite autoincrement=false nullable=false locking=false update-lock=true default-fetch=false / field-descriptor name=salespointId column=salespoint_id jdbc-type=BIGINT primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=userId column=user_id jdbc-type=BIGINT primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=foreignCurrencyId column=foreign_currency_id jdbc-type=BIGINT primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=status column=status jdbc-type=INTEGER primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=settlement column=settlement jdbc-type=BIGINT primarykey=false indexed=true nullable=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / field-descriptor name=amount column=amount jdbc-type=DOUBLE primarykey=false nullable=true indexed=false autoincrement=false locking=false update-lock=true default-fetch=false access=readwrite / reference-descriptor name=salespoint class-ref=ch.eugster.pos.db.Salespoint proxy=false refresh=false auto-retrieve=true auto-update=false auto-delete=false otm-dependent=false foreignkey field-ref=salespointId / /reference-descriptor reference-descriptor name=user class-ref=ch.eugster.pos.db.User proxy=false refresh=false auto-retrieve=true auto-update=false auto-delete=false otm-dependent=false foreignkey field-ref=userId / /reference-descriptor reference-descriptor name=foreignCurrency class-ref=ch.eugster.pos.db.ForeignCurrency proxy=false refresh=false auto-retrieve=true auto-update=false auto-delete=false otm-dependent=false foreignkey field-ref=foreignCurrencyId / /reference-descriptor collection-descriptor name=positions element-class-ref=ch.eugster.pos.db.Position auto-retrieve=true auto-update=true auto-delete=true sort=ASC proxy=false refresh=false otm-dependent=false orderby name=id sort=ASC / inverse-foreignkey field-ref=receiptId / /collection-descriptor
Re: [ANN] OJB 1.0rc7 Released
To me, default doesn't matters... Just be really clear in DOCS that the changes are made, because I've a near to 265000 loc here that uses either RemovalAware and Non-RemovalAware behaviour... Best regards, Edson Richter Armin Waibel wrote: Steve Clark wrote: Armin Waibel writes: Armin ooh, seems I made a mistake in the test cases repository I Armin don't specified a non-removeaware collection-class. Maybe Armin I should read the docs before I start writing the next test Armin cases ;-). Not to beat a dead horse, but I think this is yet another very clear demonstration that the default behavior is counterintuitive. It really seems that it would be better for non-RemovalAwareCollection to be the default, with RemovalAwareCollection available as an option for those who want that behavior. I agree with you, but some time ago the argument for using RemovalAwareCollections as default collection-class was to make PB-api delete collection objects behaviour similar to the ODMG-api. I don't know when we change collection-class, but originally non-RemovalAwareCollection was used as default one. If most OJB user vote for an rollback to non-RAC, we can switch back again (hopefully the last time ;-)). As an alternative I will have a look in source and try to make default collection-class pluggable via OJB.properties file. If it will be possible, we can satisfy both strategies. regards, Armin - 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: RE : OJB and RMI
Tom: Thanks for all your help. Sometimes a fresh set of eyes can really help. The problem was a misspelled path on the OJB.properties location. Now you can get back to your usual task of helping solve real OJB problems. thanks again. Brad At 06:31 PM 6/15/2004 +0200, you wrote: Bradford Pielech wrote: Tom: Thanks for the pointer, but it still isn't working. Here is some sample code inside the RMI server that illustrates the failure: String s = RMIClassLoader.getClassAnnotation(PersistenceBrokerFactory.class); ClassLoader cl = RMIClassLoader.getClassLoader(s); org.apache.ojb.broker.util.ClassHelper.setClassLoader(cl); PersistenceBroker pbroker = PersistenceBrokerFactory.defaultPersistenceBroker(); System.out.println(PBroker: + pbroker.toString()); This produces the error: --- [BOOT] ERROR: Creation of PersistenceBrokerFactory (PBF) instance failed, can't get PBF class object -- Any other ideas? Hmm, I'm by no means an RMI expert (at least in environments where performance is not an issue, I'd rather use XML-RPC), but I wonder whether the RMI classloader is correctly initialized to find OJB classes, or whether OJB is correctly configured. Have a look into your OJB.properties file to see what the persistence broker factory class is that would used (property PersistenceBrokerFactoryClass). If this property is not defined, then the above error results (there is no default value for this property). If it is defined, then either the OJB.properties file could not be loaded (you should see this in the same log where the above error message was output), or the class could not be loaded. In the first case, the OJB.properties file could probably not loaded (you can set its path manually using the system property OJB.properties prior to using *any* OJB class). In the latter case, please try to load the class directly using the RMI classloader: Class.forName(classname, true, cl); and see what happens then. Tom - 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: RE : OJB and RMI
Bradford Pielech wrote: Tom: Thanks for all your help. Sometimes a fresh set of eyes can really help. The problem was a misspelled path on the OJB.properties location. Did you get a log message about that ? If not, then I should add one to make this easier for the next person with the same problem. Now you can get back to your usual task of helping solve real OJB problems. thanks again. No problem! Just for the record: do you have to use ClassHelper#setClassLoader to make it work with RMI ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : OJB and RMI
Bradford Pielech wrote: No, we didnt see any error messages relating to this, probably because the logging configuration is set in OJB.properties. Well not exactly for two reasons: in rc7 and newer, logging settings can (and should) be specified in a separate file OJB-logging.properties. Also, a missing OJB.properties file should be noted in the boot log which does not need to be configured (it simply prints to stdout; e.g. the error message that you got is probably from the boot logger). I'll check the handling of a missing properties file. No, we did not need to do that. All we needed to do was make sure OJB.properties, spy.properties, and the various repository.xml files could be found. There wasn't any RMI specific steps that needed to be taken beyond granting permission in the RMI.policy file. We didnt even need to add ojb.jar to the codebase list. That's nice then, no need to configure OJB to make it work with RMI :-) Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : OJB and RMI
No, we didnt see any error messages relating to this, probably because the logging configuration is set in OJB.properties. Did you get a log message about that ? If not, then I should add one to make this easier for the next person with the same problem. No problem! Just for the record: do you have to use ClassHelper#setClassLoader to make it work with RMI ? No, we did not need to do that. All we needed to do was make sure OJB.properties, spy.properties, and the various repository.xml files could be found. There wasn't any RMI specific steps that needed to be taken beyond granting permission in the RMI.policy file. We didnt even need to add ojb.jar to the codebase list. Brad Tom - 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]
New Warnings in Managed Environment with RC7
I am now getting the following warnings in a JTA environment (this worked fine, no messages, before RC7): 2004-06-15 13:32:26,728 WARN [Servlet.Engine.Transports : 0] No running tx found, please only delete objects in context of an PB-transaction, to avoid side-effects - e.g. when rollback of complex objects (org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java)) Looking into the code, it appears as though I am now required to do a pb.beginTransaction() in even a managed environment. Am I missing something? Thanks for all your hard work, Gary __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Warnings in Managed Environment with RC7
Hi Gary, Gary wrote: I am now getting the following warnings in a JTA environment (this worked fine, no messages, before RC7): 2004-06-15 13:32:26,728 WARN [Servlet.Engine.Transports : 0] No running tx found, please only delete objects in context of an PB-transaction, to avoid side-effects - e.g. when rollback of complex objects (org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java)) Looking into the code, it appears as though I am now required to do a pb.beginTransaction() in even a managed environment. Am I missing something? I assume you use PB-api in managed environment and when deleting an object you use a JTA-tx? Did you set PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl in OJB.properties (introduced in rc6)? regards, Armin Thanks for all your hard work, Gary __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - 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: New Warnings in Managed Environment with RC7
Armin: Thanks for the quick reply. Do you guys have a contribute site like SourceForge so I could buy you a beer? No, I wasn't using the Sync factory. When I change to it, I get a new error: 2004-06-15 15:19:29,798 ERROR [TCP Connection(7)-172.24.54.129] Connection is in local transaction, do a 'localCommit' or 'localRollback' beforeperform the connection release - rollback the connection now (org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java)) It has the following stack trace: System Thread [TCP Connection(7)-172.24.54.129] (Suspended) ConnectionManagerImpl.releaseConnection() line: 295 PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion() line: 240 PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion() line: 418 RegisteredSyncs.distributeBefore() line: 110 TransactionImpl.internalPrepare() line: 1211 TransactionImpl.commit() line: 960 TranManagerImpl.commit() line: 150 TranManagerSet.commit() line: 182 My OJB.properties is as follows: #!-- #/* Copyright 2002-2004 The Apache Software Foundation # * # * Licensed under the Apache License, Version 2.0 (the License); # * you may not use this file except in compliance with the License. # * You may obtain a copy of the License at # * # * http://www.apache.org/licenses/LICENSE-2.0 # * # * Unless required by applicable law or agreed to in writing, software # * distributed under the License is distributed on an AS IS BASIS, # * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # * See the License for the specific language governing permissions and # * limitations under the License. # */ #-- # OJB.properties -- configuration of the OJB runtime environment # Version: 1.0 # (c) 2001, 2002, 2003 Apache Software Foundation # Author: Thomas Mahler and many others # @version $Id: OJB.properties,v 1.70 2004/06/03 23:46:08 arminw Exp $ # # # repository file settings # # The repositoryFile entry tells OJB to use this file as as its standard mapping # repository. The file is looked up from the classpath. # repositoryFile=repository.xml # # If the useSerializedRepository entry is set to true, OJB tries to load a # serialized version of the repository for performance reasons. # if set to false, OJB always loads the xml file. # Setting this flag to true will accelerate the startup sequence of OJB. # If set to true changes to the repository.xml file will only be detected # after maually deleting the repository.xml.serialized file. useSerializedRepository=false # # If Repository serialization is used the entry serializedRepositoryPath defines the # directory where the Repository is written to and read from. # this entry is used only when the useSerializedRepository flag is set to true # serializedRepositoryPath=. # # # PersistenceBrokerFactory / PersistenceBroker # # The PersistenceBrokerFactoryClass entry decides which concrete # PersistenceBrokerFactory implemention is to be used. #PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl # If in managed environment *only* the PB-api was used it's recommended to use this factory # to enable the PersistenceBroker instances to participate in the JTA transaction. This makes # e.g. PBStateListener work properly in managed environments. PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl # # # The PersistenceBrokerClass entry decides which concrete PersistenceBroker # implementation is to be served by the PersistenceBrokerFactory. # This is the singlevm implementation: PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl #PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl # # This is an implementation that uses Prevayler (prevayler.sf.net) as the persistent storage. # Using this implementation OJB works as a simple OODBMS #PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl # # # PersistenceBroker pool # # PersistenceBroker pool configuration # This pool uses the jakarta-commons-pool api. # There you can find things described in detail. # # maximum number of brokers that can be borrowed from the # pool at one time. When non-positive, there is no limit. maxActive=100 # # controls the maximum number of brokers that can sit idle in the # pool (per key) at any time. When non-positive, there is no
Re: New Warnings in Managed Environment with RC7
Gary wrote: Armin: Thanks for the quick reply. Do you guys have a contribute site like SourceForge so I could buy you a beer? Think I should avoid to drink alcohol, because your problem seems really sophisticated ;-) No, I wasn't using the Sync factory. When I change to it, I get a new error: 2004-06-15 15:19:29,798 ERROR [TCP Connection(7)-172.24.54.129] Connection is in local transaction, do a 'localCommit' or 'localRollback' beforeperform the connection release - rollback the connection now (org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.releaseConnection(ConnectionManagerImpl.java)) hmm, do you close the PB instance within the used method or before the tx demarcation ends? I assume you don't. regards, Armin It has the following stack trace: System Thread [TCP Connection(7)-172.24.54.129] (Suspended) ConnectionManagerImpl.releaseConnection() line: 295 PersistenceBrokerFactorySyncImpl$PersistenceBrokerSyncImpl.beforeCompletion() line: 240 PersistenceBrokerFactorySyncImpl$TransactionBox.beforeCompletion() line: 418 RegisteredSyncs.distributeBefore() line: 110 TransactionImpl.internalPrepare() line: 1211 TransactionImpl.commit() line: 960 TranManagerImpl.commit() line: 150 TranManagerSet.commit() line: 182 My OJB.properties is as follows: #!-- #/* Copyright 2002-2004 The Apache Software Foundation # * # * Licensed under the Apache License, Version 2.0 (the License); # * you may not use this file except in compliance with the License. # * You may obtain a copy of the License at # * # * http://www.apache.org/licenses/LICENSE-2.0 # * # * Unless required by applicable law or agreed to in writing, software # * distributed under the License is distributed on an AS IS BASIS, # * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # * See the License for the specific language governing permissions and # * limitations under the License. # */ #-- # OJB.properties -- configuration of the OJB runtime environment # Version: 1.0 # (c) 2001, 2002, 2003 Apache Software Foundation # Author: Thomas Mahler and many others # @version $Id: OJB.properties,v 1.70 2004/06/03 23:46:08 arminw Exp $ # # # repository file settings # # The repositoryFile entry tells OJB to use this file as as its standard mapping # repository. The file is looked up from the classpath. # repositoryFile=repository.xml # # If the useSerializedRepository entry is set to true, OJB tries to load a # serialized version of the repository for performance reasons. # if set to false, OJB always loads the xml file. # Setting this flag to true will accelerate the startup sequence of OJB. # If set to true changes to the repository.xml file will only be detected # after maually deleting the repository.xml.serialized file. useSerializedRepository=false # # If Repository serialization is used the entry serializedRepositoryPath defines the # directory where the Repository is written to and read from. # this entry is used only when the useSerializedRepository flag is set to true # serializedRepositoryPath=. # # # PersistenceBrokerFactory / PersistenceBroker # # The PersistenceBrokerFactoryClass entry decides which concrete # PersistenceBrokerFactory implemention is to be used. #PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl # If in managed environment *only* the PB-api was used it's recommended to use this factory # to enable the PersistenceBroker instances to participate in the JTA transaction. This makes # e.g. PBStateListener work properly in managed environments. PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl # # # The PersistenceBrokerClass entry decides which concrete PersistenceBroker # implementation is to be served by the PersistenceBrokerFactory. # This is the singlevm implementation: PersistenceBrokerClass=edu.mayo.evolution.infrastructure.ojb.EvolutionPersistenceBrokerImpl #PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl # # This is an implementation that uses Prevayler (prevayler.sf.net) as the persistent storage. # Using this implementation OJB works as a simple OODBMS #PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl # # # PersistenceBroker pool # # PersistenceBroker pool configuration # This pool uses the jakarta-commons-pool api. # There you can find things described in detail. # # maximum number of brokers that
AW: Duplicate key error when inserting a new record
Hi Armin, hmm difficult to say what's going wrong. I can't find metadata for 'ch.eugster.pos.db.DBResult' class or what does this entry mean? DBResult is just an object that capsulate the information a transaction is providing me. As following: DBResult result = receipt.store(); if receipt.store() returns an errorcode, DBResult logs this to my logger. The relevant metadata are those i provided in my mail. The situation is, that some clients are - as a load-test - inserting concurrently records in the same db over a network. all clients use ojb (as i mentioned before rc5). Sometimes i get also the following error: 14.06.2004 09:41:31 ch.eugster.pos.db.Table describeError SCHWERWIEGEND: Can not init Identity for given object [EMAIL PROTECTED] where ch.eugster.pos.db.Table is the abstract superclass of ch.eugster.pos.db.Position. Does this information help you? Thank you and regards Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
