Dependency of SQL-Statements

7 Messages Forum Options Options
Embed this topic
Permalink
Josef.Eisele
Dependency of SQL-Statements
Reply Threaded MoreMore options
Print post
Permalink
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
Re: Dependency of SQL-Statements
Reply Threaded MoreMore options
Print post
Permalink
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
Antwort: Re: Dependency of SQL-Statements
Reply Threaded MoreMore options
Print post
Permalink
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
Re: Re: Dependency of SQL-Statements
Reply Threaded MoreMore options
Print post
Permalink
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
Re: Re: Dependency of SQL-Statements
Reply Threaded MoreMore options
Print post
Permalink
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
Antwort: Re: Re: Dependency of SQL-Statements
Reply Threaded MoreMore options
Print post
Permalink
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
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
>
>
>
>


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
Antwort: Re: Re: Dependency of SQL-Statements
Reply Threaded MoreMore options
Print post
Permalink
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
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
>
>
>
>


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