|
|
|
Josef.Eisele
|
Hi all,
we are using openjpa in two ways: 1) In our Geronimo Applicationserver 2.1.1 2) In our Test-Environment with openejb embedded 3.0 We have a problem in 2), which I described in a posting on the openejb-Mailinglist: On Jun 30, 2008, at 7:32 AM, Josef.Eisele@... wrote: > Hi David, > > Germany lost the Euro2008 therefore I need good news ;-) Do you have > any > for me? > > I confinced my team to use all junit-Tests with openejb as embedded > container in Eclipse :-) > > Using my tests, sometimes strange things happen: > * I test the public CRUD-functions of my business class and often I > get > the expected GREEN color as the result. > * But sometimes the first function of my business class fails. It is a > creation of the business object. The failure happens without any > code-change. > > There are two SQL-Insert-Statemens which depend on each other. We > use the > EntityManager.persist Method. Is it possible the transaction manager > in > embedded-openejb sometimes use the wrong order for the insert- > statements ? FWIU, yes. By default, OpenJPA does not reorder SQL statements to respect foreign keys. There is an UpdateManager which will respect foreign keys, but you have to turn it on with this property: openjpa .jdbc .UpdateManager=org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager BTW, this is about the limits of my knowledge of OpenJPA, so you may be better served by asking on the OpenJPA Users mailing list (users@... ). -dain => I tried the property, but nothing changed. -Josef BGS Beratungsgesellschaft Software Systemplanung AG Niederlassung Rhein/Main Robert-Koch-Straße 41 55129 Mainz Fon: +49 (0) 6131 / 914-0 Fax: +49 (0) 6131 / 914-400 www.bgs-ag.de Geschäftssitz Mainz Registergericht Amtsgericht Mainz HRB 62 50 Aufsichtsratsvorsitzender Dr. Wolfgang Trommer Vorstand Hanspeter Gau Hermann Kiefer Nils Manegold Heinz-Jörg Zimmermann |
|
Michael Dick
|
Hi Josef,
Minor clarification WRT update managers. ConstraintUpdateManager is the default UpdateManager for OpenJPA which probably explains why setting it was a no-op for you (sadly this may vary if you were using a rather old version of OpenJPA). Which version of OpenJPA are you using? Does the application work differently in Geronimo than it does in your test environment? How do the SQL statements depend on each other? The constraint update manager is able to detect when you have two related entities which use generated PK fields. If you have other implied FK relationships between two entities you may need to indicate where the key constraints exist by adding @ForeignKey annotations in your entities. For example @Entity public class Order { // OpenJPA does not assume that there is a FK constraint on shippingAddress. @OneToOne private Address shippingAddress; } @Entity public class Order { // OpenJPA is aware of a Database FK constraint. @org.apache.openjpa.persistence.jdbc.ForeignKey @OneToOne private Address shippingAddress; } Alternatively you can configure OpenJPA to read in constraints from the database by adding the following property to persistence.xml : <property name="openjpa.jdbc.SchemaFactory" value="native"/>. See http://openjpa.apache.org/docs/latest/manual/manual.html#ref_guide_schema_info_factoryfor more information on the SchemaFactory setting. Hope this helps, -mike On Tue, Jul 1, 2008 at 3:08 AM, <Josef.Eisele@...> wrote: > Hi all, > > we are using openjpa in two ways: > 1) In our Geronimo Applicationserver 2.1.1 > 2) In our Test-Environment with openejb embedded 3.0 > > We have a problem in 2), which I described in a posting on the > openejb-Mailinglist: > > On Jun 30, 2008, at 7:32 AM, Josef.Eisele@... wrote: > > > Hi David, > > > > Germany lost the Euro2008 therefore I need good news ;-) Do you have > > any > > for me? > > > > I confinced my team to use all junit-Tests with openejb as embedded > > container in Eclipse :-) > > > > Using my tests, sometimes strange things happen: > > * I test the public CRUD-functions of my business class and often I > > get > > the expected GREEN color as the result. > > * But sometimes the first function of my business class fails. It is a > > creation of the business object. The failure happens without any > > code-change. > > > > There are two SQL-Insert-Statemens which depend on each other. We > > use the > > EntityManager.persist Method. Is it possible the transaction manager > > in > > embedded-openejb sometimes use the wrong order for the insert- > > statements ? > > FWIU, yes. By default, OpenJPA does not reorder SQL statements to > respect foreign keys. There is an UpdateManager which will respect > foreign keys, but you have to turn it on with this property: > > openjpa > .jdbc > .UpdateManager=org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager > > > BTW, this is about the limits of my knowledge of OpenJPA, so you may > be better served by asking on the OpenJPA Users mailing list > (users@... > ). > > -dain > > > => I tried the property, but nothing changed. > > > -Josef > BGS Beratungsgesellschaft > Software Systemplanung AG Niederlassung Rhein/Main > Robert-Koch-Straße 41 > 55129 Mainz > Fon: +49 (0) 6131 / 914-0 > Fax: +49 (0) 6131 / 914-400 > www.bgs-ag.de Geschäftssitz Mainz > Registergericht > Amtsgericht Mainz > HRB 62 50 > Aufsichtsratsvorsitzender > Dr. Wolfgang Trommer > Vorstand > Hanspeter Gau > Hermann Kiefer > Nils Manegold > Heinz-Jörg Zimmermann > > |
||||||||||||||||||
|
Josef.Eisele
|
Hi Mike,
thanx a lot for your help. We use: 1) Geronimo 2.1.1 with openjpa-1.0.2.jar 2) OpenEJB Embedded 3.0 with openjpa-1.0.1.jar The 2 tables are linked with a foreign key: Table1PAO: @Id private long id; @OneToOne @JoinColumn(name="foreignkey_table2", referencedColumnName="id") private Table2PAO table2Pao; .... Table2PAO: @Id private long id; ... The table Table1 itself has a foreign key constraint. And here the error 'sometimes 50%' arises when code is run on 2). If the code is run in 1), we have no errrors.There are two insert-Statements, one for Table1 and one for Table2, and sometimes Table1 is done before Table2, I suppose. We don't want to change our code, only because of problems in our testing environment. As far as i understand @org.apache.openjpa.persistence.jdbc.ForeignKey is not an EJB3-Annotation? It is specific to openjpa?! Adding <property name="openjpa.jdbc.SchemaFactory" value="native"/> to persistence.xml did not help. -Josef "Michael Dick" <michael.d.dick@...> 01.07.2008 23:55 Bitte antworten an users@... An users@... Kopie Thema Re: Dependency of SQL-Statements Hi Josef, Minor clarification WRT update managers. ConstraintUpdateManager is the default UpdateManager for OpenJPA which probably explains why setting it was a no-op for you (sadly this may vary if you were using a rather old version of OpenJPA). Which version of OpenJPA are you using? Does the application work differently in Geronimo than it does in your test environment? How do the SQL statements depend on each other? The constraint update manager is able to detect when you have two related entities which use generated PK fields. If you have other implied FK relationships between two entities you may need to indicate where the key constraints exist by adding @ForeignKey annotations in your entities. For example @Entity public class Order { // OpenJPA does not assume that there is a FK constraint on shippingAddress. @OneToOne private Address shippingAddress; } @Entity public class Order { // OpenJPA is aware of a Database FK constraint. @org.apache.openjpa.persistence.jdbc.ForeignKey @OneToOne private Address shippingAddress; } Alternatively you can configure OpenJPA to read in constraints from the database by adding the following property to persistence.xml : <property name="openjpa.jdbc.SchemaFactory" value="native"/>. See http://openjpa.apache.org/docs/latest/manual/manual.html#ref_guide_schema_info_factoryfor more information on the SchemaFactory setting. Hope this helps, -mike On Tue, Jul 1, 2008 at 3:08 AM, <Josef.Eisele@...> wrote: > Hi all, > > we are using openjpa in two ways: > 1) In our Geronimo Applicationserver 2.1.1 > 2) In our Test-Environment with openejb embedded 3.0 > > We have a problem in 2), which I described in a posting on the > openejb-Mailinglist: > > On Jun 30, 2008, at 7:32 AM, Josef.Eisele@... wrote: > > > Hi David, > > > > Germany lost the Euro2008 therefore I need good news ;-) Do you have > > any > > for me? > > > > I confinced my team to use all junit-Tests with openejb as embedded > > container in Eclipse :-) > > > > Using my tests, sometimes strange things happen: > > * I test the public CRUD-functions of my business class and often I > > get > > the expected GREEN color as the result. > > * But sometimes the first function of my business class fails. It is a > > creation of the business object. The failure happens without any > > code-change. > > > > There are two SQL-Insert-Statemens which depend on each other. We > > use the > > EntityManager.persist Method. Is it possible the transaction manager > > in > > embedded-openejb sometimes use the wrong order for the insert- > > statements ? > > FWIU, yes. By default, OpenJPA does not reorder SQL statements to > respect foreign keys. There is an UpdateManager which will respect > foreign keys, but you have to turn it on with this property: > > openjpa > .jdbc > .UpdateManager=org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager > > > BTW, this is about the limits of my knowledge of OpenJPA, so you may > be better served by asking on the OpenJPA Users mailing list > (users@... > ). > > -dain > > > => I tried the property, but nothing changed. > > > -Josef > BGS Beratungsgesellschaft > Software Systemplanung AG Niederlassung Rhein/Main > Robert-Koch-Straße 41 > 55129 Mainz > Fon: +49 (0) 6131 / 914-0 > Fax: +49 (0) 6131 / 914-400 > www.bgs-ag.de Geschäftssitz Mainz > Registergericht > Amtsgericht Mainz > HRB 62 50 > Aufsichtsratsvorsitzender > Dr. Wolfgang Trommer > Vorstand > Hanspeter Gau > Hermann Kiefer > Nils Manegold > Heinz-Jörg Zimmermann > > BGS Beratungsgesellschaft Software Systemplanung AG Niederlassung Rhein/Main Robert-Koch-Straße 41 55129 Mainz Fon: +49 (0) 6131 / 914-0 Fax: +49 (0) 6131 / 914-400 www.bgs-ag.de Geschäftssitz Mainz Registergericht Amtsgericht Mainz HRB 62 50 Aufsichtsratsvorsitzender Dr. Wolfgang Trommer Vorstand Hanspeter Gau Hermann Kiefer Nils Manegold |
||||||||||||||||||
|
Michael Dick
|
Hi Josef,
I think I've reproduced the problem, and my preceding suggestion was faulty. The native SchemaFactory needs to include the parameter foreignKeys=true. What worked for me was this: <property name="openjpa.jdbc.SchemaFactory" value="native(foreignKeys=true)" /> Omitting (foreignKeys=true) caused table1 to be inserted before table2 and a FK constraint violation. Could you give this a try? -mike On Wed, Jul 2, 2008 at 6:36 AM, <Josef.Eisele@...> wrote: > Hi Mike, > > thanx a lot for your help. We use: > 1) Geronimo 2.1.1 with openjpa-1.0.2.jar > 2) OpenEJB Embedded 3.0 with openjpa-1.0.1.jar > > The 2 tables are linked with a foreign key: > > Table1PAO: > @Id > private long id; > > @OneToOne > @JoinColumn(name="foreignkey_table2", referencedColumnName="id") > private Table2PAO table2Pao; > .... > > Table2PAO: > @Id > private long id; > ... > > > The table Table1 itself has a foreign key constraint. And here the error > 'sometimes 50%' arises when code is run on 2). If the code is run in 1), > we have no errrors.There are two insert-Statements, one for Table1 and one > for Table2, and sometimes Table1 is done before Table2, I suppose. > > > We don't want to change our code, only because of problems in our testing > environment. As far as i understand > @org.apache.openjpa.persistence.jdbc.ForeignKey is not an EJB3-Annotation? > It is specific to openjpa?! > > Adding <property name="openjpa.jdbc.SchemaFactory" > value="native"/> to persistence.xml did not help. > > -Josef > > > > > "Michael Dick" <michael.d.dick@...> > 01.07.2008 23:55 > Bitte antworten an > users@... > > > An > users@... > Kopie > > Thema > Re: Dependency of SQL-Statements > > > > > > > Hi Josef, > > Minor clarification WRT update managers. ConstraintUpdateManager is the > default UpdateManager for OpenJPA which probably explains why setting it > was > a no-op for you (sadly this may vary if you were using a rather old > version > of OpenJPA). > > Which version of OpenJPA are you using? Does the application work > differently in Geronimo than it does in your test environment? > > How do the SQL statements depend on each other? The constraint update > manager is able to detect when you have two related entities which use > generated PK fields. If you have other implied FK relationships between > two > entities you may need to indicate where the key constraints exist by > adding > @ForeignKey annotations in your entities. > > For example > > @Entity > public class Order { > // OpenJPA does not assume that there is a FK constraint on > shippingAddress. > @OneToOne private Address shippingAddress; > } > > @Entity > public class Order { > // OpenJPA is aware of a Database FK constraint. > @org.apache.openjpa.persistence.jdbc.ForeignKey > @OneToOne private Address shippingAddress; > } > > Alternatively you can configure OpenJPA to read in constraints from the > database by adding the following property to persistence.xml : > <property name="openjpa.jdbc.SchemaFactory" value="native"/>. > See > > http://openjpa.apache.org/docs/latest/manual/manual.html#ref_guide_schema_info_factoryfor > > more information on the SchemaFactory setting. > > Hope this helps, > > -mike > > On Tue, Jul 1, 2008 at 3:08 AM, <Josef.Eisele@...> wrote: > > > Hi all, > > > > we are using openjpa in two ways: > > 1) In our Geronimo Applicationserver 2.1.1 > > 2) In our Test-Environment with openejb embedded 3.0 > > > > We have a problem in 2), which I described in a posting on the > > openejb-Mailinglist: > > > > On Jun 30, 2008, at 7:32 AM, Josef.Eisele@... wrote: > > > > > Hi David, > > > > > > Germany lost the Euro2008 therefore I need good news ;-) Do you have > > > any > > > for me? > > > > > > I confinced my team to use all junit-Tests with openejb as embedded > > > container in Eclipse :-) > > > > > > Using my tests, sometimes strange things happen: > > > * I test the public CRUD-functions of my business class and often I > > > get > > > the expected GREEN color as the result. > > > * But sometimes the first function of my business class fails. It is a > > > creation of the business object. The failure happens without any > > > code-change. > > > > > > There are two SQL-Insert-Statemens which depend on each other. We > > > use the > > > EntityManager.persist Method. Is it possible the transaction manager > > > in > > > embedded-openejb sometimes use the wrong order for the insert- > > > statements ? > > > > FWIU, yes. By default, OpenJPA does not reorder SQL statements to > > respect foreign keys. There is an UpdateManager which will respect > > foreign keys, but you have to turn it on with this property: > > > > openjpa > > .jdbc > > .UpdateManager=org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager > > > > > > BTW, this is about the limits of my knowledge of OpenJPA, so you may > > be better served by asking on the OpenJPA Users mailing list > > (users@... > > ). > > > > -dain > > > > > > => I tried the property, but nothing changed. > > > > > > -Josef > > BGS Beratungsgesellschaft > > Software Systemplanung AG Niederlassung Rhein/Main > > Robert-Koch-Straße 41 > > 55129 Mainz > > Fon: +49 (0) 6131 / 914-0 > > Fax: +49 (0) 6131 / 914-400 > > www.bgs-ag.de Geschäftssitz Mainz > > Registergericht > > Amtsgericht Mainz > > HRB 62 50 > > Aufsichtsratsvorsitzender > > Dr. Wolfgang Trommer > > Vorstand > > Hanspeter Gau > > Hermann Kiefer > > Nils Manegold > > Heinz-Jörg Zimmermann > > > > > > > BGS Beratungsgesellschaft > Software Systemplanung AG > > > > > Niederlassung Rhein/Main > Robert-Koch-Straße 41 > 55129 Mainz > Fon: +49 (0) 6131 / 914-0 > Fax: +49 (0) 6131 / 914-400 > www.bgs-ag.de > Geschäftssitz Mainz > Registergericht > Amtsgericht Mainz > HRB 62 50 > > Aufsichtsratsvorsitzender > Dr. Wolfgang Trommer > Vorstand > Hanspeter Gau > Hermann Kiefer > Nils Manegold > > > > |
||||||||||||||||||
|
Michael Dick
|
Hi Josef,
I found this while looking at another thread but it might help you as well. By default OpenJPA does not acknowlege implied FK constraints (ie implied by @xxxToOne annotations). You can change this behavior by adding the following configuration option : <property name="openjpa.jdbc.MappingDefaults" value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/> A little background can be found here : https://issues.apache.org/jira/browse/OPENJPA-435 The MappingDefaults property is often useful when creating or updating your existing schema with the SchemaTool or MappingTool, but it will also help with SQL ordering. I think you're trying to match the entity defitions to an existing database so the schemaFactory property is more appropriate, but I thought I should at least mention the MappingDefaults setting.. Regards, -Mike On Wed, Jul 2, 2008 at 10:37 AM, Michael Dick <michael.d.dick@...> wrote: > Hi Josef, > > I think I've reproduced the problem, and my preceding suggestion was > faulty. The native SchemaFactory needs to include the parameter > foreignKeys=true. > > What worked for me was this: > <property name="openjpa.jdbc.SchemaFactory" > value="native(foreignKeys=true)" /> > > Omitting (foreignKeys=true) caused table1 to be inserted before table2 and > a FK constraint violation. > > Could you give this a try? > > -mike > > > On Wed, Jul 2, 2008 at 6:36 AM, <Josef.Eisele@...> wrote: > >> Hi Mike, >> >> thanx a lot for your help. We use: >> 1) Geronimo 2.1.1 with openjpa-1.0.2.jar >> 2) OpenEJB Embedded 3.0 with openjpa-1.0.1.jar >> >> The 2 tables are linked with a foreign key: >> >> Table1PAO: >> @Id >> private long id; >> >> @OneToOne >> @JoinColumn(name="foreignkey_table2", referencedColumnName="id") >> private Table2PAO table2Pao; >> .... >> >> Table2PAO: >> @Id >> private long id; >> ... >> >> >> The table Table1 itself has a foreign key constraint. And here the error >> 'sometimes 50%' arises when code is run on 2). If the code is run in 1), >> we have no errrors.There are two insert-Statements, one for Table1 and one >> for Table2, and sometimes Table1 is done before Table2, I suppose. >> >> >> We don't want to change our code, only because of problems in our testing >> environment. As far as i understand >> @org.apache.openjpa.persistence.jdbc.ForeignKey is not an EJB3-Annotation? >> It is specific to openjpa?! >> >> Adding <property name="openjpa.jdbc.SchemaFactory" >> value="native"/> to persistence.xml did not help. >> >> -Josef >> >> >> >> >> "Michael Dick" <michael.d.dick@...> >> 01.07.2008 23:55 >> Bitte antworten an >> users@... >> >> >> An >> users@... >> Kopie >> >> Thema >> Re: Dependency of SQL-Statements >> >> >> >> >> >> >> Hi Josef, >> >> Minor clarification WRT update managers. ConstraintUpdateManager is the >> default UpdateManager for OpenJPA which probably explains why setting it >> was >> a no-op for you (sadly this may vary if you were using a rather old >> version >> of OpenJPA). >> >> Which version of OpenJPA are you using? Does the application work >> differently in Geronimo than it does in your test environment? >> >> How do the SQL statements depend on each other? The constraint update >> manager is able to detect when you have two related entities which use >> generated PK fields. If you have other implied FK relationships between >> two >> entities you may need to indicate where the key constraints exist by >> adding >> @ForeignKey annotations in your entities. >> >> For example >> >> @Entity >> public class Order { >> // OpenJPA does not assume that there is a FK constraint on >> shippingAddress. >> @OneToOne private Address shippingAddress; >> } >> >> @Entity >> public class Order { >> // OpenJPA is aware of a Database FK constraint. >> @org.apache.openjpa.persistence.jdbc.ForeignKey >> @OneToOne private Address shippingAddress; >> } >> >> Alternatively you can configure OpenJPA to read in constraints from the >> database by adding the following property to persistence.xml : >> <property name="openjpa.jdbc.SchemaFactory" value="native"/>. >> See >> >> http://openjpa.apache.org/docs/latest/manual/manual.html#ref_guide_schema_info_factoryfor >> >> more information on the SchemaFactory setting. >> >> Hope this helps, >> >> -mike >> >> On Tue, Jul 1, 2008 at 3:08 AM, <Josef.Eisele@...> wrote: >> >> > Hi all, >> > >> > we are using openjpa in two ways: >> > 1) In our Geronimo Applicationserver 2.1.1 >> > 2) In our Test-Environment with openejb embedded 3.0 >> > >> > We have a problem in 2), which I described in a posting on the >> > openejb-Mailinglist: >> > >> > On Jun 30, 2008, at 7:32 AM, Josef.Eisele@... wrote: >> > >> > > Hi David, >> > > >> > > Germany lost the Euro2008 therefore I need good news ;-) Do you have >> > > any >> > > for me? >> > > >> > > I confinced my team to use all junit-Tests with openejb as embedded >> > > container in Eclipse :-) >> > > >> > > Using my tests, sometimes strange things happen: >> > > * I test the public CRUD-functions of my business class and often I >> > > get >> > > the expected GREEN color as the result. >> > > * But sometimes the first function of my business class fails. It is a >> > > creation of the business object. The failure happens without any >> > > code-change. >> > > >> > > There are two SQL-Insert-Statemens which depend on each other. We >> > > use the >> > > EntityManager.persist Method. Is it possible the transaction manager >> > > in >> > > embedded-openejb sometimes use the wrong order for the insert- >> > > statements ? >> > >> > FWIU, yes. By default, OpenJPA does not reorder SQL statements to >> > respect foreign keys. There is an UpdateManager which will respect >> > foreign keys, but you have to turn it on with this property: >> > >> > openjpa >> > .jdbc >> > .UpdateManager=org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager >> > >> > >> > BTW, this is about the limits of my knowledge of OpenJPA, so you may >> > be better served by asking on the OpenJPA Users mailing list >> > (users@... >> > ). >> > >> > -dain >> > >> > >> > => I tried the property, but nothing changed. >> > >> > >> > -Josef >> > BGS Beratungsgesellschaft >> > Software Systemplanung AG Niederlassung Rhein/Main >> > Robert-Koch-Straße 41 >> > 55129 Mainz >> > Fon: +49 (0) 6131 / 914-0 >> > Fax: +49 (0) 6131 / 914-400 >> > www.bgs-ag.de Geschäftssitz Mainz >> > Registergericht >> > Amtsgericht Mainz >> > HRB 62 50 >> > Aufsichtsratsvorsitzender >> > Dr. Wolfgang Trommer >> > Vorstand >> > Hanspeter Gau >> > Hermann Kiefer >> > Nils Manegold >> > Heinz-Jörg Zimmermann >> > >> > >> >> >> BGS Beratungsgesellschaft >> Software Systemplanung AG >> >> >> >> >> Niederlassung Rhein/Main >> Robert-Koch-Straße 41 >> 55129 Mainz >> Fon: +49 (0) 6131 / 914-0 >> Fax: +49 (0) 6131 / 914-400 >> www.bgs-ag.de >> Geschäftssitz Mainz >> Registergericht >> Amtsgericht Mainz >> HRB 62 50 >> >> Aufsichtsratsvorsitzender >> Dr. Wolfgang Trommer >> Vorstand >> Hanspeter Gau >> Hermann Kiefer >> Nils Manegold >> >> >> >> > > |
||||||||||||||||||
|
Josef.Eisele
|
In reply to this post by Michael Dick
Hi Mike,
both of your options are working fine. So we can choose between two solutions :-) The only thing I don't understand is why we don't get any errors running the same code in Geronimo 2.1.1 ? There should be also sometimes a problem with foreign keys? -Josef "Michael Dick" <michael.d.dick@...> 02.07.2008 17:37 Bitte antworten an users@... An users@... Kopie Thema Re: Re: Dependency of SQL-Statements Hi Josef, I think I've reproduced the problem, and my preceding suggestion was faulty. The native SchemaFactory needs to include the parameter foreignKeys=true. What worked for me was this: <property name="openjpa.jdbc.SchemaFactory" value="native(foreignKeys=true)" /> Omitting (foreignKeys=true) caused table1 to be inserted before table2 and a FK constraint violation. Could you give this a try? -mike On Wed, Jul 2, 2008 at 6:36 AM, <Josef.Eisele@...> wrote: > Hi Mike, > > thanx a lot for your help. We use: > 1) Geronimo 2.1.1 with openjpa-1.0.2.jar > 2) OpenEJB Embedded 3.0 with openjpa-1.0.1.jar > > The 2 tables are linked with a foreign key: > > Table1PAO: > @Id > private long id; > > @OneToOne > @JoinColumn(name="foreignkey_table2", referencedColumnName="id") > private Table2PAO table2Pao; > .... > > Table2PAO: > @Id > private long id; > ... > > > The table Table1 itself has a foreign key constraint. And here the error > 'sometimes 50%' arises when code is run on 2). If the code is run in 1), > we have no errrors.There are two insert-Statements, one for Table1 and > for Table2, and sometimes Table1 is done before Table2, I suppose. > > > We don't want to change our code, only because of problems in our testing > environment. As far as i understand > @org.apache.openjpa.persistence.jdbc.ForeignKey is not an EJB3-Annotation? > It is specific to openjpa?! > > Adding <property name="openjpa.jdbc.SchemaFactory" > value="native"/> to persistence.xml did not help. > > -Josef > > > > > "Michael Dick" <michael.d.dick@...> > 01.07.2008 23:55 > Bitte antworten an > users@... > > > An > users@... > Kopie > > Thema > Re: Dependency of SQL-Statements > > > > > > > Hi Josef, > > Minor clarification WRT update managers. ConstraintUpdateManager is the > default UpdateManager for OpenJPA which probably explains why setting it > was > a no-op for you (sadly this may vary if you were using a rather old > version > of OpenJPA). > > Which version of OpenJPA are you using? Does the application work > differently in Geronimo than it does in your test environment? > > How do the SQL statements depend on each other? The constraint update > manager is able to detect when you have two related entities which use > generated PK fields. If you have other implied FK relationships between > two > entities you may need to indicate where the key constraints exist by > adding > @ForeignKey annotations in your entities. > > For example > > @Entity > public class Order { > // OpenJPA does not assume that there is a FK constraint on > shippingAddress. > @OneToOne private Address shippingAddress; > } > > @Entity > public class Order { > // OpenJPA is aware of a Database FK constraint. > @org.apache.openjpa.persistence.jdbc.ForeignKey > @OneToOne private Address shippingAddress; > } > > Alternatively you can configure OpenJPA to read in constraints from the > database by adding the following property to persistence.xml : > <property name="openjpa.jdbc.SchemaFactory" value="native"/>. > See > > > > more information on the SchemaFactory setting. > > Hope this helps, > > -mike > > On Tue, Jul 1, 2008 at 3:08 AM, <Josef.Eisele@...> wrote: > > > Hi all, > > > > we are using openjpa in two ways: > > 1) In our Geronimo Applicationserver 2.1.1 > > 2) In our Test-Environment with openejb embedded 3.0 > > > > We have a problem in 2), which I described in a posting on the > > openejb-Mailinglist: > > > > On Jun 30, 2008, at 7:32 AM, Josef.Eisele@... wrote: > > > > > Hi David, > > > > > > Germany lost the Euro2008 therefore I need good news ;-) Do you have > > > any > > > for me? > > > > > > I confinced my team to use all junit-Tests with openejb as embedded > > > container in Eclipse :-) > > > > > > Using my tests, sometimes strange things happen: > > > * I test the public CRUD-functions of my business class and often I > > > get > > > the expected GREEN color as the result. > > > * But sometimes the first function of my business class fails. It is > > > creation of the business object. The failure happens without any > > > code-change. > > > > > > There are two SQL-Insert-Statemens which depend on each other. We > > > use the > > > EntityManager.persist Method. Is it possible the transaction manager > > > in > > > embedded-openejb sometimes use the wrong order for the insert- > > > statements ? > > > > FWIU, yes. By default, OpenJPA does not reorder SQL statements to > > respect foreign keys. There is an UpdateManager which will respect > > foreign keys, but you have to turn it on with this property: > > > > openjpa > > .jdbc > > .UpdateManager=org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager > > > > > > BTW, this is about the limits of my knowledge of OpenJPA, so you may > > be better served by asking on the OpenJPA Users mailing list > > (users@... > > ). > > > > -dain > > > > > > => I tried the property, but nothing changed. > > > > > > -Josef > > BGS Beratungsgesellschaft > > Software Systemplanung AG Niederlassung Rhein/Main > > Robert-Koch-Straße 41 > > 55129 Mainz > > Fon: +49 (0) 6131 / 914-0 > > Fax: +49 (0) 6131 / 914-400 > > www.bgs-ag.de Geschäftssitz Mainz > > Registergericht > > Amtsgericht Mainz > > HRB 62 50 > > Aufsichtsratsvorsitzender > > Dr. Wolfgang Trommer > > Vorstand > > Hanspeter Gau > > Hermann Kiefer > > Nils Manegold > > Heinz-Jörg Zimmermann > > > > > > > BGS Beratungsgesellschaft > Software Systemplanung AG > > > > > Niederlassung Rhein/Main > Robert-Koch-Straße 41 > 55129 Mainz > Fon: +49 (0) 6131 / 914-0 > Fax: +49 (0) 6131 / 914-400 > www.bgs-ag.de > Geschäftssitz Mainz > Registergericht > Amtsgericht Mainz > HRB 62 50 > > Aufsichtsratsvorsitzender > Dr. Wolfgang Trommer > Vorstand > Hanspeter Gau > Hermann Kiefer > Nils Manegold > > > > BGS Beratungsgesellschaft Software Systemplanung AG Niederlassung Rhein/Main Robert-Koch-Straße 41 55129 Mainz Fon: +49 (0) 6131 / 914-0 Fax: +49 (0) 6131 / 914-400 www.bgs-ag.de Geschäftssitz Mainz Registergericht Amtsgericht Mainz HRB 62 50 Aufsichtsratsvorsitzender Dr. Wolfgang Trommer Vorstand Hanspeter Gau Hermann Kiefer Nils Manegold |
||||||||||||||||||
|
Josef.Eisele
|
Hi Mike,
I was too fast with my praise... I tried it 5 times and therefore I thought it is working fine. But a co-worker of mine has a more difficult unit-test, with about 5 inserts and it is at no time in the right order. I checked my log-File and I see the 2 inserts of my test: 2008-07-11 15:44:58,441 - DEBUG - <t 49194, conn 0> executing prepstmnt 24646280 INSERT 2 2008-07-11 15:44:58,486 - DEBUG - <t 49194, conn 0> [45 ms] spent 2008-07-11 15:44:58,498 - DEBUG - <t 49194, conn 0> executing prepstmnt 5190593 INSERT 1 INSERT 1 should be before INSERT 2 :-( I heard something about a 'database running in batch-mode'. All statements are called in the order of creation. Can this be a solution?? Is there a property to tell JPA to make all statements in the order of creation? -Josef Josef.Eisele@... 04.07.2008 09:16 Bitte antworten an users@... An users@... Kopie Thema Antwort: Re: Re: Dependency of SQL-Statements Hi Mike, both of your options are working fine. So we can choose between two solutions :-) The only thing I don't understand is why we don't get any errors running the same code in Geronimo 2.1.1 ? There should be also sometimes a problem with foreign keys? -Josef "Michael Dick" <michael.d.dick@...> 02.07.2008 17:37 Bitte antworten an users@... An users@... Kopie Thema Re: Re: Dependency of SQL-Statements Hi Josef, I think I've reproduced the problem, and my preceding suggestion was faulty. The native SchemaFactory needs to include the parameter foreignKeys=true. What worked for me was this: <property name="openjpa.jdbc.SchemaFactory" value="native(foreignKeys=true)" /> Omitting (foreignKeys=true) caused table1 to be inserted before table2 and a FK constraint violation. Could you give this a try? -mike On Wed, Jul 2, 2008 at 6:36 AM, <Josef.Eisele@...> wrote: > Hi Mike, > > thanx a lot for your help. We use: > 1) Geronimo 2.1.1 with openjpa-1.0.2.jar > 2) OpenEJB Embedded 3.0 with openjpa-1.0.1.jar > > The 2 tables are linked with a foreign key: > > Table1PAO: > @Id > private long id; > > @OneToOne > @JoinColumn(name="foreignkey_table2", referencedColumnName="id") > private Table2PAO table2Pao; > .... > > Table2PAO: > @Id > private long id; > ... > > > The table Table1 itself has a foreign key constraint. And here the error > 'sometimes 50%' arises when code is run on 2). If the code is run in 1), > we have no errrors.There are two insert-Statements, one for Table1 and > for Table2, and sometimes Table1 is done before Table2, I suppose. > > > We don't want to change our code, only because of problems in our testing > environment. As far as i understand > @org.apache.openjpa.persistence.jdbc.ForeignKey is not an EJB3-Annotation? > It is specific to openjpa?! > > Adding <property name="openjpa.jdbc.SchemaFactory" > value="native"/> to persistence.xml did not help. > > -Josef > > > > > "Michael Dick" <michael.d.dick@...> > 01.07.2008 23:55 > Bitte antworten an > users@... > > > An > users@... > Kopie > > Thema > Re: Dependency of SQL-Statements > > > > > > > Hi Josef, > > Minor clarification WRT update managers. ConstraintUpdateManager is the > default UpdateManager for OpenJPA which probably explains why setting it > was > a no-op for you (sadly this may vary if you were using a rather old > version > of OpenJPA). > > Which version of OpenJPA are you using? Does the application work > differently in Geronimo than it does in your test environment? > > How do the SQL statements depend on each other? The constraint update > manager is able to detect when you have two related entities which use > generated PK fields. If you have other implied FK relationships between > two > entities you may need to indicate where the key constraints exist by > adding > @ForeignKey annotations in your entities. > > For example > > @Entity > public class Order { > // OpenJPA does not assume that there is a FK constraint on > shippingAddress. > @OneToOne private Address shippingAddress; > } > > @Entity > public class Order { > // OpenJPA is aware of a Database FK constraint. > @org.apache.openjpa.persistence.jdbc.ForeignKey > @OneToOne private Address shippingAddress; > } > > Alternatively you can configure OpenJPA to read in constraints from the > database by adding the following property to persistence.xml : > <property name="openjpa.jdbc.SchemaFactory" value="native"/>. > See > > > > more information on the SchemaFactory setting. > > Hope this helps, > > -mike > > On Tue, Jul 1, 2008 at 3:08 AM, <Josef.Eisele@...> wrote: > > > Hi all, > > > > we are using openjpa in two ways: > > 1) In our Geronimo Applicationserver 2.1.1 > > 2) In our Test-Environment with openejb embedded 3.0 > > > > We have a problem in 2), which I described in a posting on the > > openejb-Mailinglist: > > > > On Jun 30, 2008, at 7:32 AM, Josef.Eisele@... wrote: > > > > > Hi David, > > > > > > Germany lost the Euro2008 therefore I need good news ;-) Do you have > > > any > > > for me? > > > > > > I confinced my team to use all junit-Tests with openejb as embedded > > > container in Eclipse :-) > > > > > > Using my tests, sometimes strange things happen: > > > * I test the public CRUD-functions of my business class and often I > > > get > > > the expected GREEN color as the result. > > > * But sometimes the first function of my business class fails. It is a > > > creation of the business object. The failure happens without any > > > code-change. > > > > > > There are two SQL-Insert-Statemens which depend on each other. We > > > use the > > > EntityManager.persist Method. Is it possible the transaction manager > > > in > > > embedded-openejb sometimes use the wrong order for the insert- > > > statements ? > > > > FWIU, yes. By default, OpenJPA does not reorder SQL statements to > > respect foreign keys. There is an UpdateManager which will respect > > foreign keys, but you have to turn it on with this property: > > > > openjpa > > .jdbc > > .UpdateManager=org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager > > > > > > BTW, this is about the limits of my knowledge of OpenJPA, so you may > > be better served by asking on the OpenJPA Users mailing list > > (users@... > > ). > > > > -dain > > > > > > => I tried the property, but nothing changed. > > > > > > -Josef > > BGS Beratungsgesellschaft > > Software Systemplanung AG Niederlassung Rhein/Main > > Robert-Koch-Straße 41 > > 55129 Mainz > > Fon: +49 (0) 6131 / 914-0 > > Fax: +49 (0) 6131 / 914-400 > > www.bgs-ag.de Geschäftssitz Mainz > > Registergericht > > Amtsgericht Mainz > > HRB 62 50 > > Aufsichtsratsvorsitzender > > Dr. Wolfgang Trommer > > Vorstand > > Hanspeter Gau > > Hermann Kiefer > > Nils Manegold > > Heinz-Jörg Zimmermann > > > > > > > BGS Beratungsgesellschaft > Software Systemplanung AG > > > > > Niederlassung Rhein/Main > Robert-Koch-Straße 41 > 55129 Mainz > Fon: +49 (0) 6131 / 914-0 > Fax: +49 (0) 6131 / 914-400 > www.bgs-ag.de > Geschäftssitz Mainz > Registergericht > Amtsgericht Mainz > HRB 62 50 > > Aufsichtsratsvorsitzender > Dr. Wolfgang Trommer > Vorstand > Hanspeter Gau > Hermann Kiefer > Nils Manegold > > > > BGS Beratungsgesellschaft Software Systemplanung AG Niederlassung Rhein/Main Robert-Koch-Straße 41 55129 Mainz Fon: +49 (0) 6131 / 914-0 Fax: +49 (0) 6131 / 914-400 www.bgs-ag.de Geschäftssitz Mainz Registergericht Amtsgericht Mainz HRB 62 50 Aufsichtsratsvorsitzender Dr. Wolfgang Trommer Vorstand Hanspeter Gau Hermann Kiefer Nils Manegold BGS Beratungsgesellschaft Software Systemplanung AG Niederlassung Rhein/Main Robert-Koch-Straße 41 55129 Mainz Fon: +49 (0) 6131 / 914-0 Fax: +49 (0) 6131 / 914-400 www.bgs-ag.de Geschäftssitz Mainz Registergericht Amtsgericht Mainz HRB 62 50 Aufsichtsratsvorsitzender Dr. Wolfgang Trommer Vorstand Hanspeter Gau Hermann Kiefer Nils Manegold |
||||||||||||||||||
| Free Forum Powered by Nabble | Forum Help |