You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Shubbis <ma...@broadpark.no> on 2009/03/12 13:22:04 UTC
Slow performance with OpenJPA when selecting from a ManyToMany
relation.
First post so bare with me, and I've search for quite a while and not found
any answers.
I'm working on a school project where we are testing performance with
different ORM's compared to JDBC and I'm having a big issue with OpenJPA
when using a ManyToMany relation.
We're trying to do a simple select case where we run a for loop with 500
iterations while calling a findById method that returns the instance.
Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes 10+
sec on OpenJPA.
This only happens with ManyToMany! We have plenty of insert tests, select
tests etc and all of them are much more similar, with openjpa winning and
losing a few.
Now, I'll gladly admit we dont have to much experience with this, but this
strikes me as very odd. So, if anyone has any tips, comments or info I'll be
glad to try it out.
Thanks in advance!
Marius
Here are the two entities in question:
package project.common.model;
import java.util.*;
import javax.persistence.*;
@Entity
public class Wearhouse {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer wearhouseNr;
private String wearhouseName;
@ManyToMany(cascade={CascadeType.PERSIST}, fetch = FetchType.EAGER)
@JoinTable(
name="wearhouse_storagecategory",
joinColumns=@JoinColumn(name="wearhouseNr"),
inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
)
private List<Storagecategory> storageCategories;
public Wearhouse() {
}
public Wearhouse(String wearhouseName) {
this.wearhouseName = wearhouseName;
storageCategories = new ArrayList<Storagecategory>();
}
public Integer getWearhouseNr() {
return this.wearhouseNr;
}
public void setWearhouseNr(Integer wearhouseNr) {
this.wearhouseNr = wearhouseNr;
}
public String getWearhouseName() {
return this.wearhouseName;
}
public void setWearhouseName(String wearhouseName) {
this.wearhouseName = wearhouseName;
}
public void setStorageCategories(List<Storagecategory> storageCategory){
this.storageCategories = storageCategory;
}
public List<Storagecategory> getStorageCategories(){
return storageCategories;
}
public void addStorageCategories(Storagecategory storagecategory) {
if(storageCategories == null)
storageCategories = new ArrayList<Storagecategory>();
storageCategories.add(storagecategory);
}
}
package project.common.model;
import java.util.*;
import javax.persistence.*;
@Entity
public class Storagecategory {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer storagecategoryNr;
private String storageCategoryName;
@ManyToMany(mappedBy="storageCategories", cascade={CascadeType.PERSIST})
private List<Wearhouse> wearhouses;
public Storagecategory() {
}
public Storagecategory(String storageCategoryName) {
this.storageCategoryName = storageCategoryName;
}
public Integer getStoragecategoryNr() {
return this.storagecategoryNr;
}
public void setStoragecategoryNr(Integer storagecategoryNr) {
this.storagecategoryNr = storagecategoryNr;
}
public String getStorageCategoryName() {
return this.storageCategoryName;
}
public void setStorageCategoryName(String storageCategoryName) {
this.storageCategoryName = storageCategoryName;
}
public List<Wearhouse> getWearhouses() {
return wearhouses;
}
public void setWearhouses(List<Wearhouse> wearhouses) {
this.wearhouses = wearhouses;
//Wearhouse owns the relation, therefor we have to tell these
//wearhouses this storargecategories is on of the wearhouse's
storagecategories.
for (Wearhouse wearhouse : wearhouses)
wearhouse.addStorageCategories(this);
}
}
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Jeremy Bauer <te...@gmail.com>.
Shubbis,
Thanks for your reply and for your willingness to give my suggestion a try.
My question was mainly to (indirectly) point out that emf & em creation is
costly (especially emf) and that it could skew results. Since your
measurement procedure tosses out high & low values, even if you create the
em during the first exec in your test cycle the measurement procedure would
likely toss out that result. That being the case, creating the em ahead of
time should not show any better results. Unless your test suite executes
the ManyToMany tests first and reuses that em for all following tests,
which, from your description is not the case, other tests should have been
similarly affected. But, it may still be worth verifying.
What issue did you have with the 1.2.x nightly build? A vote is currently
underway to publish a new 1.2.x release soon so please post if you've found
a problem.
-Jeremy
On Thu, Mar 12, 2009 at 2:26 PM, Shubbis <ma...@broadpark.no> wrote:
>
> Hi Jeremy!
>
> Our tests get (or create) the em when we begin the measurement. This is
> done
> on all the frameworks and all the tests (selects, inserts, updates,
> deletes,
> etc.). We then remove the highest and lowest numbers from all the results
> and gather an average. Should this really be affected? I mean, wouldn't
> that
> be a problem on all the selects and not only the ManyToMany if that was the
> case?
>
> Don't get me wrong, I'm going to give it a go, but I just want to make sure
> our scenario is understood.
>
> Also we are using MySQL 5.1.
>
> I've also tried to run the test on my local mysql installation and the
> results are similar, actually a bit slower..
>
>
>
> Jeremy Bauer wrote:
> >
> > Hi Shubbis,
> >
> > Does your measurement include the time it takes to create the entity
> > manager
> > factory and/or entity manager or are they created before you execute the
> > find operations? I'm guessing you create the em ahead of time, since the
> > ManyToMany result is atypical. But if so, could you try creating the em
> > before taking measurement? That would factor out any em initialization
> > related issues. Also, which db platform are you using for the tests?
> >
> > -Jeremy
> >
> > On Thu, Mar 12, 2009 at 8:48 AM, Shubbis <ma...@broadpark.no>
> > wrote:
> >
> >>
> >> Hi Kevin,
> >>
> >> Thanks for the reply!
> >>
> >> We are enhancing the files. I have an Ant script enhancing the files
> >> before
> >> every run of OpenJPA, so that is not the problem.
> >> Although it did give me strange results the first time I tried openjpa
> >> and
> >> did not enhance ;)
> >>
> >> -Shubbis
> >>
> >>
> >> Kevin Sutter wrote:
> >> >
> >> > Hi Shubbis,
> >> > Thanks for asking before posting any results... :-) Much
> appreciated.
> >> >
> >> > The first thing that comes to mind is whether you are "enhancing" your
> >> > Entities that are used with OpenJPA. For optimal performance, OpenJPA
> >> > uses
> >> > a byte-code weaving technique to enhance the Entity objects. This
> >> > enhancement allows for more efficient interaction between the Entity
> >> > objects
> >> > and the OpenJPA runtime.
> >> >
> >> > This blog entry explains the various enhancement mechanisms available
> >> for
> >> > an
> >> > OpenJPA environment (build vs runtime):
> >> >
> >>
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
> >> >
> >> > FYI, if you do not perform the byte-code enhancement either statically
> >> at
> >> > build time or dynamically at runtime, then OpenJPA falls back to a
> >> simpler
> >> > subclassing approach. This subclassing approach is meant for simple
> >> > out-of-the-box examples, and not for production or performance
> >> > comparisons.
> >> > This performance concern becomes especially noticeable with Eager type
> >> > relationship fetching like it looks your example is doing.
> >> >
> >> > Let's start with this enhancement processing. If you are doing
> >> > enhancement
> >> > and you are still hitting this performance concern, then we need to
> dig
> >> > further because we definitely do not see this type of performance
> >> concern
> >> > when we do our comparisons... :-)
> >> >
> >> > Thanks,
> >> > Kevin
> >> >
> >> > On Thu, Mar 12, 2009 at 7:22 AM, Shubbis <ma...@broadpark.no>
> >> > wrote:
> >> >
> >> >>
> >> >> First post so bare with me, and I've search for quite a while and not
> >> >> found
> >> >> any answers.
> >> >>
> >> >> I'm working on a school project where we are testing performance with
> >> >> different ORM's compared to JDBC and I'm having a big issue with
> >> OpenJPA
> >> >> when using a ManyToMany relation.
> >> >>
> >> >> We're trying to do a simple select case where we run a for loop with
> >> 500
> >> >> iterations while calling a findById method that returns the instance.
> >> >>
> >> >> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class,
> id);
> >> >>
> >> >> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes
> >> 10+
> >> >> sec on OpenJPA.
> >> >> This only happens with ManyToMany! We have plenty of insert tests,
> >> select
> >> >> tests etc and all of them are much more similar, with openjpa winning
> >> and
> >> >> losing a few.
> >> >>
> >> >> Now, I'll gladly admit we dont have to much experience with this, but
> >> >> this
> >> >> strikes me as very odd. So, if anyone has any tips, comments or info
> >> I'll
> >> >> be
> >> >> glad to try it out.
> >> >>
> >> >> Thanks in advance!
> >> >>
> >> >> Marius
> >> >>
> >> >> Here are the two entities in question:
> >> >>
> >> >> package project.common.model;
> >> >>
> >> >> import java.util.*;
> >> >>
> >> >> import javax.persistence.*;
> >> >>
> >> >> @Entity
> >> >> public class Wearhouse {
> >> >>
> >> >> @Id
> >> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
> >> >> private Integer wearhouseNr;
> >> >> private String wearhouseName;
> >> >>
> >> >> @ManyToMany(cascade={CascadeType.PERSIST}, fetch =
> >> >> FetchType.EAGER)
> >> >> @JoinTable(
> >> >> name="wearhouse_storagecategory",
> >> >> joinColumns=@JoinColumn(name="wearhouseNr"),
> >> >>
> >> >> inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
> >> >> )
> >> >> private List<Storagecategory> storageCategories;
> >> >>
> >> >> public Wearhouse() {
> >> >> }
> >> >>
> >> >> public Wearhouse(String wearhouseName) {
> >> >> this.wearhouseName = wearhouseName;
> >> >> storageCategories = new ArrayList<Storagecategory>();
> >> >> }
> >> >>
> >> >> public Integer getWearhouseNr() {
> >> >> return this.wearhouseNr;
> >> >> }
> >> >>
> >> >> public void setWearhouseNr(Integer wearhouseNr) {
> >> >> this.wearhouseNr = wearhouseNr;
> >> >> }
> >> >>
> >> >> public String getWearhouseName() {
> >> >> return this.wearhouseName;
> >> >> }
> >> >>
> >> >> public void setWearhouseName(String wearhouseName) {
> >> >> this.wearhouseName = wearhouseName;
> >> >> }
> >> >>
> >> >> public void setStorageCategories(List<Storagecategory>
> >> >> storageCategory){
> >> >> this.storageCategories = storageCategory;
> >> >> }
> >> >>
> >> >> public List<Storagecategory> getStorageCategories(){
> >> >> return storageCategories;
> >> >> }
> >> >>
> >> >> public void addStorageCategories(Storagecategory
> >> storagecategory)
> >> >> {
> >> >> if(storageCategories == null)
> >> >> storageCategories = new
> >> >> ArrayList<Storagecategory>();
> >> >> storageCategories.add(storagecategory);
> >> >>
> >> >> }
> >> >>
> >> >> }
> >> >>
> >> >>
> >> >>
> >> >> package project.common.model;
> >> >>
> >> >> import java.util.*;
> >> >>
> >> >> import javax.persistence.*;
> >> >>
> >> >> @Entity
> >> >> public class Storagecategory {
> >> >>
> >> >> @Id
> >> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
> >> >> private Integer storagecategoryNr;
> >> >> private String storageCategoryName;
> >> >>
> >> >> @ManyToMany(mappedBy="storageCategories",
> >> >> cascade={CascadeType.PERSIST})
> >> >> private List<Wearhouse> wearhouses;
> >> >>
> >> >> public Storagecategory() {
> >> >> }
> >> >>
> >> >> public Storagecategory(String storageCategoryName) {
> >> >> this.storageCategoryName = storageCategoryName;
> >> >> }
> >> >>
> >> >> public Integer getStoragecategoryNr() {
> >> >> return this.storagecategoryNr;
> >> >> }
> >> >>
> >> >> public void setStoragecategoryNr(Integer storagecategoryNr) {
> >> >> this.storagecategoryNr = storagecategoryNr;
> >> >> }
> >> >>
> >> >> public String getStorageCategoryName() {
> >> >> return this.storageCategoryName;
> >> >> }
> >> >>
> >> >> public void setStorageCategoryName(String storageCategoryName)
> >> {
> >> >> this.storageCategoryName = storageCategoryName;
> >> >> }
> >> >>
> >> >> public List<Wearhouse> getWearhouses() {
> >> >> return wearhouses;
> >> >> }
> >> >>
> >> >> public void setWearhouses(List<Wearhouse> wearhouses) {
> >> >> this.wearhouses = wearhouses;
> >> >>
> >> >> //Wearhouse owns the relation, therefor we have to
> tell
> >> >> these
> >> >> //wearhouses this storargecategories is on of the
> >> >> wearhouse's
> >> >> storagecategories.
> >> >> for (Wearhouse wearhouse : wearhouses)
> >> >> wearhouse.addStorageCategories(this);
> >> >> }
> >> >> }
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
> >> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2467417.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2469498.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Hi Jeremy!
Our tests get (or create) the em when we begin the measurement. This is done
on all the frameworks and all the tests (selects, inserts, updates, deletes,
etc.). We then remove the highest and lowest numbers from all the results
and gather an average. Should this really be affected? I mean, wouldn't that
be a problem on all the selects and not only the ManyToMany if that was the
case?
Don't get me wrong, I'm going to give it a go, but I just want to make sure
our scenario is understood.
Also we are using MySQL 5.1.
I've also tried to run the test on my local mysql installation and the
results are similar, actually a bit slower..
Jeremy Bauer wrote:
>
> Hi Shubbis,
>
> Does your measurement include the time it takes to create the entity
> manager
> factory and/or entity manager or are they created before you execute the
> find operations? I'm guessing you create the em ahead of time, since the
> ManyToMany result is atypical. But if so, could you try creating the em
> before taking measurement? That would factor out any em initialization
> related issues. Also, which db platform are you using for the tests?
>
> -Jeremy
>
> On Thu, Mar 12, 2009 at 8:48 AM, Shubbis <ma...@broadpark.no>
> wrote:
>
>>
>> Hi Kevin,
>>
>> Thanks for the reply!
>>
>> We are enhancing the files. I have an Ant script enhancing the files
>> before
>> every run of OpenJPA, so that is not the problem.
>> Although it did give me strange results the first time I tried openjpa
>> and
>> did not enhance ;)
>>
>> -Shubbis
>>
>>
>> Kevin Sutter wrote:
>> >
>> > Hi Shubbis,
>> > Thanks for asking before posting any results... :-) Much appreciated.
>> >
>> > The first thing that comes to mind is whether you are "enhancing" your
>> > Entities that are used with OpenJPA. For optimal performance, OpenJPA
>> > uses
>> > a byte-code weaving technique to enhance the Entity objects. This
>> > enhancement allows for more efficient interaction between the Entity
>> > objects
>> > and the OpenJPA runtime.
>> >
>> > This blog entry explains the various enhancement mechanisms available
>> for
>> > an
>> > OpenJPA environment (build vs runtime):
>> >
>> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
>> >
>> > FYI, if you do not perform the byte-code enhancement either statically
>> at
>> > build time or dynamically at runtime, then OpenJPA falls back to a
>> simpler
>> > subclassing approach. This subclassing approach is meant for simple
>> > out-of-the-box examples, and not for production or performance
>> > comparisons.
>> > This performance concern becomes especially noticeable with Eager type
>> > relationship fetching like it looks your example is doing.
>> >
>> > Let's start with this enhancement processing. If you are doing
>> > enhancement
>> > and you are still hitting this performance concern, then we need to dig
>> > further because we definitely do not see this type of performance
>> concern
>> > when we do our comparisons... :-)
>> >
>> > Thanks,
>> > Kevin
>> >
>> > On Thu, Mar 12, 2009 at 7:22 AM, Shubbis <ma...@broadpark.no>
>> > wrote:
>> >
>> >>
>> >> First post so bare with me, and I've search for quite a while and not
>> >> found
>> >> any answers.
>> >>
>> >> I'm working on a school project where we are testing performance with
>> >> different ORM's compared to JDBC and I'm having a big issue with
>> OpenJPA
>> >> when using a ManyToMany relation.
>> >>
>> >> We're trying to do a simple select case where we run a for loop with
>> 500
>> >> iterations while calling a findById method that returns the instance.
>> >>
>> >> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
>> >>
>> >> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes
>> 10+
>> >> sec on OpenJPA.
>> >> This only happens with ManyToMany! We have plenty of insert tests,
>> select
>> >> tests etc and all of them are much more similar, with openjpa winning
>> and
>> >> losing a few.
>> >>
>> >> Now, I'll gladly admit we dont have to much experience with this, but
>> >> this
>> >> strikes me as very odd. So, if anyone has any tips, comments or info
>> I'll
>> >> be
>> >> glad to try it out.
>> >>
>> >> Thanks in advance!
>> >>
>> >> Marius
>> >>
>> >> Here are the two entities in question:
>> >>
>> >> package project.common.model;
>> >>
>> >> import java.util.*;
>> >>
>> >> import javax.persistence.*;
>> >>
>> >> @Entity
>> >> public class Wearhouse {
>> >>
>> >> @Id
>> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> >> private Integer wearhouseNr;
>> >> private String wearhouseName;
>> >>
>> >> @ManyToMany(cascade={CascadeType.PERSIST}, fetch =
>> >> FetchType.EAGER)
>> >> @JoinTable(
>> >> name="wearhouse_storagecategory",
>> >> joinColumns=@JoinColumn(name="wearhouseNr"),
>> >>
>> >> inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
>> >> )
>> >> private List<Storagecategory> storageCategories;
>> >>
>> >> public Wearhouse() {
>> >> }
>> >>
>> >> public Wearhouse(String wearhouseName) {
>> >> this.wearhouseName = wearhouseName;
>> >> storageCategories = new ArrayList<Storagecategory>();
>> >> }
>> >>
>> >> public Integer getWearhouseNr() {
>> >> return this.wearhouseNr;
>> >> }
>> >>
>> >> public void setWearhouseNr(Integer wearhouseNr) {
>> >> this.wearhouseNr = wearhouseNr;
>> >> }
>> >>
>> >> public String getWearhouseName() {
>> >> return this.wearhouseName;
>> >> }
>> >>
>> >> public void setWearhouseName(String wearhouseName) {
>> >> this.wearhouseName = wearhouseName;
>> >> }
>> >>
>> >> public void setStorageCategories(List<Storagecategory>
>> >> storageCategory){
>> >> this.storageCategories = storageCategory;
>> >> }
>> >>
>> >> public List<Storagecategory> getStorageCategories(){
>> >> return storageCategories;
>> >> }
>> >>
>> >> public void addStorageCategories(Storagecategory
>> storagecategory)
>> >> {
>> >> if(storageCategories == null)
>> >> storageCategories = new
>> >> ArrayList<Storagecategory>();
>> >> storageCategories.add(storagecategory);
>> >>
>> >> }
>> >>
>> >> }
>> >>
>> >>
>> >>
>> >> package project.common.model;
>> >>
>> >> import java.util.*;
>> >>
>> >> import javax.persistence.*;
>> >>
>> >> @Entity
>> >> public class Storagecategory {
>> >>
>> >> @Id
>> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> >> private Integer storagecategoryNr;
>> >> private String storageCategoryName;
>> >>
>> >> @ManyToMany(mappedBy="storageCategories",
>> >> cascade={CascadeType.PERSIST})
>> >> private List<Wearhouse> wearhouses;
>> >>
>> >> public Storagecategory() {
>> >> }
>> >>
>> >> public Storagecategory(String storageCategoryName) {
>> >> this.storageCategoryName = storageCategoryName;
>> >> }
>> >>
>> >> public Integer getStoragecategoryNr() {
>> >> return this.storagecategoryNr;
>> >> }
>> >>
>> >> public void setStoragecategoryNr(Integer storagecategoryNr) {
>> >> this.storagecategoryNr = storagecategoryNr;
>> >> }
>> >>
>> >> public String getStorageCategoryName() {
>> >> return this.storageCategoryName;
>> >> }
>> >>
>> >> public void setStorageCategoryName(String storageCategoryName)
>> {
>> >> this.storageCategoryName = storageCategoryName;
>> >> }
>> >>
>> >> public List<Wearhouse> getWearhouses() {
>> >> return wearhouses;
>> >> }
>> >>
>> >> public void setWearhouses(List<Wearhouse> wearhouses) {
>> >> this.wearhouses = wearhouses;
>> >>
>> >> //Wearhouse owns the relation, therefor we have to tell
>> >> these
>> >> //wearhouses this storargecategories is on of the
>> >> wearhouse's
>> >> storagecategories.
>> >> for (Wearhouse wearhouse : wearhouses)
>> >> wearhouse.addStorageCategories(this);
>> >> }
>> >> }
>> >> --
>> >> View this message in context:
>> >>
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
>> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2467417.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2469498.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Jeremy Bauer <te...@gmail.com>.
Hi Shubbis,
Does your measurement include the time it takes to create the entity manager
factory and/or entity manager or are they created before you execute the
find operations? I'm guessing you create the em ahead of time, since the
ManyToMany result is atypical. But if so, could you try creating the em
before taking measurement? That would factor out any em initialization
related issues. Also, which db platform are you using for the tests?
-Jeremy
On Thu, Mar 12, 2009 at 8:48 AM, Shubbis <ma...@broadpark.no> wrote:
>
> Hi Kevin,
>
> Thanks for the reply!
>
> We are enhancing the files. I have an Ant script enhancing the files before
> every run of OpenJPA, so that is not the problem.
> Although it did give me strange results the first time I tried openjpa and
> did not enhance ;)
>
> -Shubbis
>
>
> Kevin Sutter wrote:
> >
> > Hi Shubbis,
> > Thanks for asking before posting any results... :-) Much appreciated.
> >
> > The first thing that comes to mind is whether you are "enhancing" your
> > Entities that are used with OpenJPA. For optimal performance, OpenJPA
> > uses
> > a byte-code weaving technique to enhance the Entity objects. This
> > enhancement allows for more efficient interaction between the Entity
> > objects
> > and the OpenJPA runtime.
> >
> > This blog entry explains the various enhancement mechanisms available for
> > an
> > OpenJPA environment (build vs runtime):
> >
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
> >
> > FYI, if you do not perform the byte-code enhancement either statically at
> > build time or dynamically at runtime, then OpenJPA falls back to a
> simpler
> > subclassing approach. This subclassing approach is meant for simple
> > out-of-the-box examples, and not for production or performance
> > comparisons.
> > This performance concern becomes especially noticeable with Eager type
> > relationship fetching like it looks your example is doing.
> >
> > Let's start with this enhancement processing. If you are doing
> > enhancement
> > and you are still hitting this performance concern, then we need to dig
> > further because we definitely do not see this type of performance concern
> > when we do our comparisons... :-)
> >
> > Thanks,
> > Kevin
> >
> > On Thu, Mar 12, 2009 at 7:22 AM, Shubbis <ma...@broadpark.no>
> > wrote:
> >
> >>
> >> First post so bare with me, and I've search for quite a while and not
> >> found
> >> any answers.
> >>
> >> I'm working on a school project where we are testing performance with
> >> different ORM's compared to JDBC and I'm having a big issue with OpenJPA
> >> when using a ManyToMany relation.
> >>
> >> We're trying to do a simple select case where we run a for loop with 500
> >> iterations while calling a findById method that returns the instance.
> >>
> >> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
> >>
> >> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes
> 10+
> >> sec on OpenJPA.
> >> This only happens with ManyToMany! We have plenty of insert tests,
> select
> >> tests etc and all of them are much more similar, with openjpa winning
> and
> >> losing a few.
> >>
> >> Now, I'll gladly admit we dont have to much experience with this, but
> >> this
> >> strikes me as very odd. So, if anyone has any tips, comments or info
> I'll
> >> be
> >> glad to try it out.
> >>
> >> Thanks in advance!
> >>
> >> Marius
> >>
> >> Here are the two entities in question:
> >>
> >> package project.common.model;
> >>
> >> import java.util.*;
> >>
> >> import javax.persistence.*;
> >>
> >> @Entity
> >> public class Wearhouse {
> >>
> >> @Id
> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
> >> private Integer wearhouseNr;
> >> private String wearhouseName;
> >>
> >> @ManyToMany(cascade={CascadeType.PERSIST}, fetch =
> >> FetchType.EAGER)
> >> @JoinTable(
> >> name="wearhouse_storagecategory",
> >> joinColumns=@JoinColumn(name="wearhouseNr"),
> >>
> >> inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
> >> )
> >> private List<Storagecategory> storageCategories;
> >>
> >> public Wearhouse() {
> >> }
> >>
> >> public Wearhouse(String wearhouseName) {
> >> this.wearhouseName = wearhouseName;
> >> storageCategories = new ArrayList<Storagecategory>();
> >> }
> >>
> >> public Integer getWearhouseNr() {
> >> return this.wearhouseNr;
> >> }
> >>
> >> public void setWearhouseNr(Integer wearhouseNr) {
> >> this.wearhouseNr = wearhouseNr;
> >> }
> >>
> >> public String getWearhouseName() {
> >> return this.wearhouseName;
> >> }
> >>
> >> public void setWearhouseName(String wearhouseName) {
> >> this.wearhouseName = wearhouseName;
> >> }
> >>
> >> public void setStorageCategories(List<Storagecategory>
> >> storageCategory){
> >> this.storageCategories = storageCategory;
> >> }
> >>
> >> public List<Storagecategory> getStorageCategories(){
> >> return storageCategories;
> >> }
> >>
> >> public void addStorageCategories(Storagecategory storagecategory)
> >> {
> >> if(storageCategories == null)
> >> storageCategories = new
> >> ArrayList<Storagecategory>();
> >> storageCategories.add(storagecategory);
> >>
> >> }
> >>
> >> }
> >>
> >>
> >>
> >> package project.common.model;
> >>
> >> import java.util.*;
> >>
> >> import javax.persistence.*;
> >>
> >> @Entity
> >> public class Storagecategory {
> >>
> >> @Id
> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
> >> private Integer storagecategoryNr;
> >> private String storageCategoryName;
> >>
> >> @ManyToMany(mappedBy="storageCategories",
> >> cascade={CascadeType.PERSIST})
> >> private List<Wearhouse> wearhouses;
> >>
> >> public Storagecategory() {
> >> }
> >>
> >> public Storagecategory(String storageCategoryName) {
> >> this.storageCategoryName = storageCategoryName;
> >> }
> >>
> >> public Integer getStoragecategoryNr() {
> >> return this.storagecategoryNr;
> >> }
> >>
> >> public void setStoragecategoryNr(Integer storagecategoryNr) {
> >> this.storagecategoryNr = storagecategoryNr;
> >> }
> >>
> >> public String getStorageCategoryName() {
> >> return this.storageCategoryName;
> >> }
> >>
> >> public void setStorageCategoryName(String storageCategoryName) {
> >> this.storageCategoryName = storageCategoryName;
> >> }
> >>
> >> public List<Wearhouse> getWearhouses() {
> >> return wearhouses;
> >> }
> >>
> >> public void setWearhouses(List<Wearhouse> wearhouses) {
> >> this.wearhouses = wearhouses;
> >>
> >> //Wearhouse owns the relation, therefor we have to tell
> >> these
> >> //wearhouses this storargecategories is on of the
> >> wearhouse's
> >> storagecategories.
> >> for (Wearhouse wearhouse : wearhouses)
> >> wearhouse.addStorageCategories(this);
> >> }
> >> }
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2467417.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
I wish it were that easy aswell.. ;)
The database has, at the time of testing, 200 in wearhouse, 500 in
storagecategory and 10 storage categories in each wearhouse. I'm running
1.2.x. I gave the latest nightly a go, but had some issues and went back to
1.2 because of the importance of having a working installation for the
project.
Caching is default, so disabled. If i enable caching the first go still
takes just as long, but the next iterations obviously take only a few ms.
Basically it's just plain vanilla, since we cannot be expected to know all
of the frameworks tweaks and possibilities we decided to leave them all
default so we could have an even comparison. Obviously with the exception of
enhancing files for OpenJPA.
We really appreciate the help btw! :)
Kevin Sutter wrote:
>
> Shubbis,
> Darn, I thought it was going to be an easy "lack of enhancement"
> question... Your results don't seem to mesh what we have been
> experiencing,
> but let me try to mimic your exact setup and see what I come up with.
>
> I do see that you are using Eager FetchType. Is your database fully
> populated? That is, what number of Wearhouse and StorageContainers are
> you
> running with? And, have you verified that the FetchType of Eager is
> working
> for all implementations?
>
> And, what version of OpenJPA are you running with? 1.0.x, 1.2.x, 1.3.x,
> or
> trunk (2.0.x)? And, any caching parameters at all? Or, just plain
> vanilla
> out-of-the-box configuration?
>
> Thanks,
> Kevin
>
> On Thu, Mar 12, 2009 at 8:48 AM, Shubbis <ma...@broadpark.no>
> wrote:
>
>>
>> Hi Kevin,
>>
>> Thanks for the reply!
>>
>> We are enhancing the files. I have an Ant script enhancing the files
>> before
>> every run of OpenJPA, so that is not the problem.
>> Although it did give me strange results the first time I tried openjpa
>> and
>> did not enhance ;)
>>
>> -Shubbis
>>
>>
>> Kevin Sutter wrote:
>> >
>> > Hi Shubbis,
>> > Thanks for asking before posting any results... :-) Much appreciated.
>> >
>> > The first thing that comes to mind is whether you are "enhancing" your
>> > Entities that are used with OpenJPA. For optimal performance, OpenJPA
>> > uses
>> > a byte-code weaving technique to enhance the Entity objects. This
>> > enhancement allows for more efficient interaction between the Entity
>> > objects
>> > and the OpenJPA runtime.
>> >
>> > This blog entry explains the various enhancement mechanisms available
>> for
>> > an
>> > OpenJPA environment (build vs runtime):
>> >
>> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
>> >
>> > FYI, if you do not perform the byte-code enhancement either statically
>> at
>> > build time or dynamically at runtime, then OpenJPA falls back to a
>> simpler
>> > subclassing approach. This subclassing approach is meant for simple
>> > out-of-the-box examples, and not for production or performance
>> > comparisons.
>> > This performance concern becomes especially noticeable with Eager type
>> > relationship fetching like it looks your example is doing.
>> >
>> > Let's start with this enhancement processing. If you are doing
>> > enhancement
>> > and you are still hitting this performance concern, then we need to dig
>> > further because we definitely do not see this type of performance
>> concern
>> > when we do our comparisons... :-)
>> >
>> > Thanks,
>> > Kevin
>> >
>> > On Thu, Mar 12, 2009 at 7:22 AM, Shubbis <ma...@broadpark.no>
>> > wrote:
>> >
>> >>
>> >> First post so bare with me, and I've search for quite a while and not
>> >> found
>> >> any answers.
>> >>
>> >> I'm working on a school project where we are testing performance with
>> >> different ORM's compared to JDBC and I'm having a big issue with
>> OpenJPA
>> >> when using a ManyToMany relation.
>> >>
>> >> We're trying to do a simple select case where we run a for loop with
>> 500
>> >> iterations while calling a findById method that returns the instance.
>> >>
>> >> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
>> >>
>> >> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes
>> 10+
>> >> sec on OpenJPA.
>> >> This only happens with ManyToMany! We have plenty of insert tests,
>> select
>> >> tests etc and all of them are much more similar, with openjpa winning
>> and
>> >> losing a few.
>> >>
>> >> Now, I'll gladly admit we dont have to much experience with this, but
>> >> this
>> >> strikes me as very odd. So, if anyone has any tips, comments or info
>> I'll
>> >> be
>> >> glad to try it out.
>> >>
>> >> Thanks in advance!
>> >>
>> >> Marius
>> >>
>> >> Here are the two entities in question:
>> >>
>> >> package project.common.model;
>> >>
>> >> import java.util.*;
>> >>
>> >> import javax.persistence.*;
>> >>
>> >> @Entity
>> >> public class Wearhouse {
>> >>
>> >> @Id
>> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> >> private Integer wearhouseNr;
>> >> private String wearhouseName;
>> >>
>> >> @ManyToMany(cascade={CascadeType.PERSIST}, fetch =
>> >> FetchType.EAGER)
>> >> @JoinTable(
>> >> name="wearhouse_storagecategory",
>> >> joinColumns=@JoinColumn(name="wearhouseNr"),
>> >>
>> >> inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
>> >> )
>> >> private List<Storagecategory> storageCategories;
>> >>
>> >> public Wearhouse() {
>> >> }
>> >>
>> >> public Wearhouse(String wearhouseName) {
>> >> this.wearhouseName = wearhouseName;
>> >> storageCategories = new ArrayList<Storagecategory>();
>> >> }
>> >>
>> >> public Integer getWearhouseNr() {
>> >> return this.wearhouseNr;
>> >> }
>> >>
>> >> public void setWearhouseNr(Integer wearhouseNr) {
>> >> this.wearhouseNr = wearhouseNr;
>> >> }
>> >>
>> >> public String getWearhouseName() {
>> >> return this.wearhouseName;
>> >> }
>> >>
>> >> public void setWearhouseName(String wearhouseName) {
>> >> this.wearhouseName = wearhouseName;
>> >> }
>> >>
>> >> public void setStorageCategories(List<Storagecategory>
>> >> storageCategory){
>> >> this.storageCategories = storageCategory;
>> >> }
>> >>
>> >> public List<Storagecategory> getStorageCategories(){
>> >> return storageCategories;
>> >> }
>> >>
>> >> public void addStorageCategories(Storagecategory
>> storagecategory)
>> >> {
>> >> if(storageCategories == null)
>> >> storageCategories = new
>> >> ArrayList<Storagecategory>();
>> >> storageCategories.add(storagecategory);
>> >>
>> >> }
>> >>
>> >> }
>> >>
>> >>
>> >>
>> >> package project.common.model;
>> >>
>> >> import java.util.*;
>> >>
>> >> import javax.persistence.*;
>> >>
>> >> @Entity
>> >> public class Storagecategory {
>> >>
>> >> @Id
>> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> >> private Integer storagecategoryNr;
>> >> private String storageCategoryName;
>> >>
>> >> @ManyToMany(mappedBy="storageCategories",
>> >> cascade={CascadeType.PERSIST})
>> >> private List<Wearhouse> wearhouses;
>> >>
>> >> public Storagecategory() {
>> >> }
>> >>
>> >> public Storagecategory(String storageCategoryName) {
>> >> this.storageCategoryName = storageCategoryName;
>> >> }
>> >>
>> >> public Integer getStoragecategoryNr() {
>> >> return this.storagecategoryNr;
>> >> }
>> >>
>> >> public void setStoragecategoryNr(Integer storagecategoryNr) {
>> >> this.storagecategoryNr = storagecategoryNr;
>> >> }
>> >>
>> >> public String getStorageCategoryName() {
>> >> return this.storageCategoryName;
>> >> }
>> >>
>> >> public void setStorageCategoryName(String storageCategoryName)
>> {
>> >> this.storageCategoryName = storageCategoryName;
>> >> }
>> >>
>> >> public List<Wearhouse> getWearhouses() {
>> >> return wearhouses;
>> >> }
>> >>
>> >> public void setWearhouses(List<Wearhouse> wearhouses) {
>> >> this.wearhouses = wearhouses;
>> >>
>> >> //Wearhouse owns the relation, therefor we have to tell
>> >> these
>> >> //wearhouses this storargecategories is on of the
>> >> wearhouse's
>> >> storagecategories.
>> >> for (Wearhouse wearhouse : wearhouses)
>> >> wearhouse.addStorageCategories(this);
>> >> }
>> >> }
>> >> --
>> >> View this message in context:
>> >>
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
>> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2467417.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2469415.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Kevin Sutter <kw...@gmail.com>.
Shubbis,
Darn, I thought it was going to be an easy "lack of enhancement"
question... Your results don't seem to mesh what we have been experiencing,
but let me try to mimic your exact setup and see what I come up with.
I do see that you are using Eager FetchType. Is your database fully
populated? That is, what number of Wearhouse and StorageContainers are you
running with? And, have you verified that the FetchType of Eager is working
for all implementations?
And, what version of OpenJPA are you running with? 1.0.x, 1.2.x, 1.3.x, or
trunk (2.0.x)? And, any caching parameters at all? Or, just plain vanilla
out-of-the-box configuration?
Thanks,
Kevin
On Thu, Mar 12, 2009 at 8:48 AM, Shubbis <ma...@broadpark.no> wrote:
>
> Hi Kevin,
>
> Thanks for the reply!
>
> We are enhancing the files. I have an Ant script enhancing the files before
> every run of OpenJPA, so that is not the problem.
> Although it did give me strange results the first time I tried openjpa and
> did not enhance ;)
>
> -Shubbis
>
>
> Kevin Sutter wrote:
> >
> > Hi Shubbis,
> > Thanks for asking before posting any results... :-) Much appreciated.
> >
> > The first thing that comes to mind is whether you are "enhancing" your
> > Entities that are used with OpenJPA. For optimal performance, OpenJPA
> > uses
> > a byte-code weaving technique to enhance the Entity objects. This
> > enhancement allows for more efficient interaction between the Entity
> > objects
> > and the OpenJPA runtime.
> >
> > This blog entry explains the various enhancement mechanisms available for
> > an
> > OpenJPA environment (build vs runtime):
> >
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
> >
> > FYI, if you do not perform the byte-code enhancement either statically at
> > build time or dynamically at runtime, then OpenJPA falls back to a
> simpler
> > subclassing approach. This subclassing approach is meant for simple
> > out-of-the-box examples, and not for production or performance
> > comparisons.
> > This performance concern becomes especially noticeable with Eager type
> > relationship fetching like it looks your example is doing.
> >
> > Let's start with this enhancement processing. If you are doing
> > enhancement
> > and you are still hitting this performance concern, then we need to dig
> > further because we definitely do not see this type of performance concern
> > when we do our comparisons... :-)
> >
> > Thanks,
> > Kevin
> >
> > On Thu, Mar 12, 2009 at 7:22 AM, Shubbis <ma...@broadpark.no>
> > wrote:
> >
> >>
> >> First post so bare with me, and I've search for quite a while and not
> >> found
> >> any answers.
> >>
> >> I'm working on a school project where we are testing performance with
> >> different ORM's compared to JDBC and I'm having a big issue with OpenJPA
> >> when using a ManyToMany relation.
> >>
> >> We're trying to do a simple select case where we run a for loop with 500
> >> iterations while calling a findById method that returns the instance.
> >>
> >> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
> >>
> >> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes
> 10+
> >> sec on OpenJPA.
> >> This only happens with ManyToMany! We have plenty of insert tests,
> select
> >> tests etc and all of them are much more similar, with openjpa winning
> and
> >> losing a few.
> >>
> >> Now, I'll gladly admit we dont have to much experience with this, but
> >> this
> >> strikes me as very odd. So, if anyone has any tips, comments or info
> I'll
> >> be
> >> glad to try it out.
> >>
> >> Thanks in advance!
> >>
> >> Marius
> >>
> >> Here are the two entities in question:
> >>
> >> package project.common.model;
> >>
> >> import java.util.*;
> >>
> >> import javax.persistence.*;
> >>
> >> @Entity
> >> public class Wearhouse {
> >>
> >> @Id
> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
> >> private Integer wearhouseNr;
> >> private String wearhouseName;
> >>
> >> @ManyToMany(cascade={CascadeType.PERSIST}, fetch =
> >> FetchType.EAGER)
> >> @JoinTable(
> >> name="wearhouse_storagecategory",
> >> joinColumns=@JoinColumn(name="wearhouseNr"),
> >>
> >> inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
> >> )
> >> private List<Storagecategory> storageCategories;
> >>
> >> public Wearhouse() {
> >> }
> >>
> >> public Wearhouse(String wearhouseName) {
> >> this.wearhouseName = wearhouseName;
> >> storageCategories = new ArrayList<Storagecategory>();
> >> }
> >>
> >> public Integer getWearhouseNr() {
> >> return this.wearhouseNr;
> >> }
> >>
> >> public void setWearhouseNr(Integer wearhouseNr) {
> >> this.wearhouseNr = wearhouseNr;
> >> }
> >>
> >> public String getWearhouseName() {
> >> return this.wearhouseName;
> >> }
> >>
> >> public void setWearhouseName(String wearhouseName) {
> >> this.wearhouseName = wearhouseName;
> >> }
> >>
> >> public void setStorageCategories(List<Storagecategory>
> >> storageCategory){
> >> this.storageCategories = storageCategory;
> >> }
> >>
> >> public List<Storagecategory> getStorageCategories(){
> >> return storageCategories;
> >> }
> >>
> >> public void addStorageCategories(Storagecategory storagecategory)
> >> {
> >> if(storageCategories == null)
> >> storageCategories = new
> >> ArrayList<Storagecategory>();
> >> storageCategories.add(storagecategory);
> >>
> >> }
> >>
> >> }
> >>
> >>
> >>
> >> package project.common.model;
> >>
> >> import java.util.*;
> >>
> >> import javax.persistence.*;
> >>
> >> @Entity
> >> public class Storagecategory {
> >>
> >> @Id
> >> @GeneratedValue(strategy = GenerationType.IDENTITY)
> >> private Integer storagecategoryNr;
> >> private String storageCategoryName;
> >>
> >> @ManyToMany(mappedBy="storageCategories",
> >> cascade={CascadeType.PERSIST})
> >> private List<Wearhouse> wearhouses;
> >>
> >> public Storagecategory() {
> >> }
> >>
> >> public Storagecategory(String storageCategoryName) {
> >> this.storageCategoryName = storageCategoryName;
> >> }
> >>
> >> public Integer getStoragecategoryNr() {
> >> return this.storagecategoryNr;
> >> }
> >>
> >> public void setStoragecategoryNr(Integer storagecategoryNr) {
> >> this.storagecategoryNr = storagecategoryNr;
> >> }
> >>
> >> public String getStorageCategoryName() {
> >> return this.storageCategoryName;
> >> }
> >>
> >> public void setStorageCategoryName(String storageCategoryName) {
> >> this.storageCategoryName = storageCategoryName;
> >> }
> >>
> >> public List<Wearhouse> getWearhouses() {
> >> return wearhouses;
> >> }
> >>
> >> public void setWearhouses(List<Wearhouse> wearhouses) {
> >> this.wearhouses = wearhouses;
> >>
> >> //Wearhouse owns the relation, therefor we have to tell
> >> these
> >> //wearhouses this storargecategories is on of the
> >> wearhouse's
> >> storagecategories.
> >> for (Wearhouse wearhouse : wearhouses)
> >> wearhouse.addStorageCategories(this);
> >> }
> >> }
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2467417.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Hi Kevin,
Thanks for the reply!
We are enhancing the files. I have an Ant script enhancing the files before
every run of OpenJPA, so that is not the problem.
Although it did give me strange results the first time I tried openjpa and
did not enhance ;)
-Shubbis
Kevin Sutter wrote:
>
> Hi Shubbis,
> Thanks for asking before posting any results... :-) Much appreciated.
>
> The first thing that comes to mind is whether you are "enhancing" your
> Entities that are used with OpenJPA. For optimal performance, OpenJPA
> uses
> a byte-code weaving technique to enhance the Entity objects. This
> enhancement allows for more efficient interaction between the Entity
> objects
> and the OpenJPA runtime.
>
> This blog entry explains the various enhancement mechanisms available for
> an
> OpenJPA environment (build vs runtime):
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
>
> FYI, if you do not perform the byte-code enhancement either statically at
> build time or dynamically at runtime, then OpenJPA falls back to a simpler
> subclassing approach. This subclassing approach is meant for simple
> out-of-the-box examples, and not for production or performance
> comparisons.
> This performance concern becomes especially noticeable with Eager type
> relationship fetching like it looks your example is doing.
>
> Let's start with this enhancement processing. If you are doing
> enhancement
> and you are still hitting this performance concern, then we need to dig
> further because we definitely do not see this type of performance concern
> when we do our comparisons... :-)
>
> Thanks,
> Kevin
>
> On Thu, Mar 12, 2009 at 7:22 AM, Shubbis <ma...@broadpark.no>
> wrote:
>
>>
>> First post so bare with me, and I've search for quite a while and not
>> found
>> any answers.
>>
>> I'm working on a school project where we are testing performance with
>> different ORM's compared to JDBC and I'm having a big issue with OpenJPA
>> when using a ManyToMany relation.
>>
>> We're trying to do a simple select case where we run a for loop with 500
>> iterations while calling a findById method that returns the instance.
>>
>> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
>>
>> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes 10+
>> sec on OpenJPA.
>> This only happens with ManyToMany! We have plenty of insert tests, select
>> tests etc and all of them are much more similar, with openjpa winning and
>> losing a few.
>>
>> Now, I'll gladly admit we dont have to much experience with this, but
>> this
>> strikes me as very odd. So, if anyone has any tips, comments or info I'll
>> be
>> glad to try it out.
>>
>> Thanks in advance!
>>
>> Marius
>>
>> Here are the two entities in question:
>>
>> package project.common.model;
>>
>> import java.util.*;
>>
>> import javax.persistence.*;
>>
>> @Entity
>> public class Wearhouse {
>>
>> @Id
>> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> private Integer wearhouseNr;
>> private String wearhouseName;
>>
>> @ManyToMany(cascade={CascadeType.PERSIST}, fetch =
>> FetchType.EAGER)
>> @JoinTable(
>> name="wearhouse_storagecategory",
>> joinColumns=@JoinColumn(name="wearhouseNr"),
>>
>> inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
>> )
>> private List<Storagecategory> storageCategories;
>>
>> public Wearhouse() {
>> }
>>
>> public Wearhouse(String wearhouseName) {
>> this.wearhouseName = wearhouseName;
>> storageCategories = new ArrayList<Storagecategory>();
>> }
>>
>> public Integer getWearhouseNr() {
>> return this.wearhouseNr;
>> }
>>
>> public void setWearhouseNr(Integer wearhouseNr) {
>> this.wearhouseNr = wearhouseNr;
>> }
>>
>> public String getWearhouseName() {
>> return this.wearhouseName;
>> }
>>
>> public void setWearhouseName(String wearhouseName) {
>> this.wearhouseName = wearhouseName;
>> }
>>
>> public void setStorageCategories(List<Storagecategory>
>> storageCategory){
>> this.storageCategories = storageCategory;
>> }
>>
>> public List<Storagecategory> getStorageCategories(){
>> return storageCategories;
>> }
>>
>> public void addStorageCategories(Storagecategory storagecategory)
>> {
>> if(storageCategories == null)
>> storageCategories = new
>> ArrayList<Storagecategory>();
>> storageCategories.add(storagecategory);
>>
>> }
>>
>> }
>>
>>
>>
>> package project.common.model;
>>
>> import java.util.*;
>>
>> import javax.persistence.*;
>>
>> @Entity
>> public class Storagecategory {
>>
>> @Id
>> @GeneratedValue(strategy = GenerationType.IDENTITY)
>> private Integer storagecategoryNr;
>> private String storageCategoryName;
>>
>> @ManyToMany(mappedBy="storageCategories",
>> cascade={CascadeType.PERSIST})
>> private List<Wearhouse> wearhouses;
>>
>> public Storagecategory() {
>> }
>>
>> public Storagecategory(String storageCategoryName) {
>> this.storageCategoryName = storageCategoryName;
>> }
>>
>> public Integer getStoragecategoryNr() {
>> return this.storagecategoryNr;
>> }
>>
>> public void setStoragecategoryNr(Integer storagecategoryNr) {
>> this.storagecategoryNr = storagecategoryNr;
>> }
>>
>> public String getStorageCategoryName() {
>> return this.storageCategoryName;
>> }
>>
>> public void setStorageCategoryName(String storageCategoryName) {
>> this.storageCategoryName = storageCategoryName;
>> }
>>
>> public List<Wearhouse> getWearhouses() {
>> return wearhouses;
>> }
>>
>> public void setWearhouses(List<Wearhouse> wearhouses) {
>> this.wearhouses = wearhouses;
>>
>> //Wearhouse owns the relation, therefor we have to tell
>> these
>> //wearhouses this storargecategories is on of the
>> wearhouse's
>> storagecategories.
>> for (Wearhouse wearhouse : wearhouses)
>> wearhouse.addStorageCategories(this);
>> }
>> }
>> --
>> View this message in context:
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2467417.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Shubbis,
Thanks for asking before posting any results... :-) Much appreciated.
The first thing that comes to mind is whether you are "enhancing" your
Entities that are used with OpenJPA. For optimal performance, OpenJPA uses
a byte-code weaving technique to enhance the Entity objects. This
enhancement allows for more efficient interaction between the Entity objects
and the OpenJPA runtime.
This blog entry explains the various enhancement mechanisms available for an
OpenJPA environment (build vs runtime):
http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
FYI, if you do not perform the byte-code enhancement either statically at
build time or dynamically at runtime, then OpenJPA falls back to a simpler
subclassing approach. This subclassing approach is meant for simple
out-of-the-box examples, and not for production or performance comparisons.
This performance concern becomes especially noticeable with Eager type
relationship fetching like it looks your example is doing.
Let's start with this enhancement processing. If you are doing enhancement
and you are still hitting this performance concern, then we need to dig
further because we definitely do not see this type of performance concern
when we do our comparisons... :-)
Thanks,
Kevin
On Thu, Mar 12, 2009 at 7:22 AM, Shubbis <ma...@broadpark.no> wrote:
>
> First post so bare with me, and I've search for quite a while and not found
> any answers.
>
> I'm working on a school project where we are testing performance with
> different ORM's compared to JDBC and I'm having a big issue with OpenJPA
> when using a ManyToMany relation.
>
> We're trying to do a simple select case where we run a for loop with 500
> iterations while calling a findById method that returns the instance.
>
> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
>
> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes 10+
> sec on OpenJPA.
> This only happens with ManyToMany! We have plenty of insert tests, select
> tests etc and all of them are much more similar, with openjpa winning and
> losing a few.
>
> Now, I'll gladly admit we dont have to much experience with this, but this
> strikes me as very odd. So, if anyone has any tips, comments or info I'll
> be
> glad to try it out.
>
> Thanks in advance!
>
> Marius
>
> Here are the two entities in question:
>
> package project.common.model;
>
> import java.util.*;
>
> import javax.persistence.*;
>
> @Entity
> public class Wearhouse {
>
> @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> private Integer wearhouseNr;
> private String wearhouseName;
>
> @ManyToMany(cascade={CascadeType.PERSIST}, fetch = FetchType.EAGER)
> @JoinTable(
> name="wearhouse_storagecategory",
> joinColumns=@JoinColumn(name="wearhouseNr"),
>
> inverseJoinColumns=@JoinColumn(name="storagecategoryNr")
> )
> private List<Storagecategory> storageCategories;
>
> public Wearhouse() {
> }
>
> public Wearhouse(String wearhouseName) {
> this.wearhouseName = wearhouseName;
> storageCategories = new ArrayList<Storagecategory>();
> }
>
> public Integer getWearhouseNr() {
> return this.wearhouseNr;
> }
>
> public void setWearhouseNr(Integer wearhouseNr) {
> this.wearhouseNr = wearhouseNr;
> }
>
> public String getWearhouseName() {
> return this.wearhouseName;
> }
>
> public void setWearhouseName(String wearhouseName) {
> this.wearhouseName = wearhouseName;
> }
>
> public void setStorageCategories(List<Storagecategory>
> storageCategory){
> this.storageCategories = storageCategory;
> }
>
> public List<Storagecategory> getStorageCategories(){
> return storageCategories;
> }
>
> public void addStorageCategories(Storagecategory storagecategory) {
> if(storageCategories == null)
> storageCategories = new
> ArrayList<Storagecategory>();
> storageCategories.add(storagecategory);
>
> }
>
> }
>
>
>
> package project.common.model;
>
> import java.util.*;
>
> import javax.persistence.*;
>
> @Entity
> public class Storagecategory {
>
> @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> private Integer storagecategoryNr;
> private String storageCategoryName;
>
> @ManyToMany(mappedBy="storageCategories",
> cascade={CascadeType.PERSIST})
> private List<Wearhouse> wearhouses;
>
> public Storagecategory() {
> }
>
> public Storagecategory(String storageCategoryName) {
> this.storageCategoryName = storageCategoryName;
> }
>
> public Integer getStoragecategoryNr() {
> return this.storagecategoryNr;
> }
>
> public void setStoragecategoryNr(Integer storagecategoryNr) {
> this.storagecategoryNr = storagecategoryNr;
> }
>
> public String getStorageCategoryName() {
> return this.storageCategoryName;
> }
>
> public void setStorageCategoryName(String storageCategoryName) {
> this.storageCategoryName = storageCategoryName;
> }
>
> public List<Wearhouse> getWearhouses() {
> return wearhouses;
> }
>
> public void setWearhouses(List<Wearhouse> wearhouses) {
> this.wearhouses = wearhouses;
>
> //Wearhouse owns the relation, therefor we have to tell
> these
> //wearhouses this storargecategories is on of the
> wearhouse's
> storagecategories.
> for (Wearhouse wearhouse : wearhouses)
> wearhouse.addStorageCategories(this);
> }
> }
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2466994.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Rick Curtis <cu...@gmail.com>.
In addition to the manual, I wrote a post about connection pooling
http://webspherepersistence.blogspot.com/2009/01/jpa-connection-pooling.html
here .
Pinaki Poddar wrote:
>
> Hi,
> I ran the Wearhouse-StorageCategory model you have posted (thank you for
> a clean test). Against 500 categories and 200 wearhouses and a cardinality
> of 10 categories per wearhouse. The domain classes were enhanced at
> build-time. The database is MySQL and the tests ran in my pedestrian
> laptop. Here are the results for finding Wearhouses 500 times in a loop.
>
> Without connection pool : 2360 ms.
> With connection pool : 734ms
>
> Given these numbers are quite in contrast with your observations, I will
> request you to post the test harness you used to measure the number, so
> that we can investigate further.
>
> Few comments:
> 1. If performance is higher priority than ordering, consider using Set<>
> instead of List<>
> 2. Consider using a connection pool, if possible [1]
>
> [1]
> http://openjpa.apache.org/faq.html#FAQ-HowdoIenableconnectionpoolinginOpenJPA%253F
>
> Regards --
>
>
> PS: "Aristotle maintained that women have fewer teeth than men; although
> he was twice married, it never occurred to him to verify this statement by
> examining his wives' mouths." --
> The Impact of Science on Society, 1952 - Bertrand Russell
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2470332.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Yep, I sure have..
Shubbis
Pinaki Poddar wrote:
>
> I do not find anything obvious in the tests that can cause the slowdown.
> Now the usual suspect: Have you enhanced Storeage/WeraHouse classes at
> build-time?
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2490593.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
actually no, it's not the simplest way.
The example I provided already works in openJpa with enums or strings,
it's only 1 line of code / 1 annotation
@PersistentCollection
given that annotation, it will already sort out everything you've
mentioned.
@PersistentCollection
private HashSet<String> myStrings=new HashSet<String>();
or
@PersistentCollection
private HashSet<MyEnum> myEnums=new HashSet<MyEnum>();
already creates a second table, a join, and already loads and persists the
2 items for you when the entity is persisted. It works great for the most
part and is really as easy as the above code. (The one exception being
another email I sent saying eager fetching seems to be broken.)
All I really wanted (and also see Craigs posting today) is to allow the
@Enumerated annotation to be allowed and used in addition to the above,
i.e.
@Enumerated(STRING)
@PersistentCollection
private HashSet<MyEnum> myEnums=new HashSet<MyEnum>();
The difference is I'm not persisting another entity, I'm persisting a
primitive or in my case a Enum which I'm considering an instance of the
Enum primitive. The concept extends to peristing other primitives like
java.util.Date too which probably works out of the box right now with
@PersistenCollection but also probably (I haven't tried it) doesn't allow
@Temporal to be annotated at the same time either.
So, to go from having just 2 of code which works but stores the ordinal
value, to having the entire setup you've describe - just to change the
persisted type from ordinal to string, seems like a seriously large work
around especially considering changing an ordinal to string for a single
enum is only 1 extra line too, @Enumerated(STRING).
On Tue, Mar 31, 2009 at 08:23:52AM -0700, Paul Copeland wrote:
> Hi Ted -
>
> Interesting point of view. I would have thought this is the plain
> vanilla "simple clean out of the box" way to persist a Collection of
> Enums or any other kind of collection.
>
> This results in a bare minimum join with two tables and a foreign key
> which is how a Collection maps into the world of relational databases
> whether you are using straight JDBC or JPA or Hibernate or brand X ORM.
> In the end you wind up with two database tables and two objects that
> model the association.
>
> - Paul
>
> On 3/31/2009 7:40 AM, Tedman Leung wrote:
>> thanks but I was hoping there was a simple clean out of the box style
>> solution. Considering the code could/should have just been a single
>> annotation to the collection, the work around looks like an awful lot
>> of work for a framework which is suppose to reduce work.
>>
>> In the end, I just used raw JDBC in a nativeQuery. At least this way
>> other developers can understand the code I've written and it's only
>> actually about 15 lines of simple straight forward code.
>>
>> thanks.
>>
>>
>> On Mon, Mar 30, 2009 at 11:16:52AM -0700, Paul Copeland wrote:
>>
>>> Hi Ted - See example code below
>>>
>>> On 3/30/2009 9:47 AM, Tedman Leung wrote:
>>>
>>>>> Isn't the same thing true that OneToMany should annotate a
>>>>> Collection of Entities? So the Enums would be a field on the
>>>>> ManyToOne side of that kind of mapping. Then you can specify
>>>>> the @Column and @Enumerated annotations on the actual field or
>>>>> property.
>>>>>
>>>> no you can't, I tried it. I can't remember the specific error but
>>>> it was along the lines of - you're not allowed to specify a column
>>>> attribute here.
>>>>
>>> Here is an example that uses the @Enumerated and @Column annotations
>>> on a OneToMany relation.
>>>
>>> This stores a Set of Enums as String values. A similar example would
>>> work for ManyToMany. The same approach can also be used with
>>> Collections of Temporal values.
>>>
>>> There are two classes - an EnumHolder that holds the Collection and
>>> an EnumValue that holds an Enum and stores it as a String. Here is
>>> the MappingTool generated SQL (Postgres database). As you can see
>>> the Enum is stored as a String VARCHAR(10).
>>>
>>> CREATE TABLE enum_holder (id BIGSERIAL NOT NULL, PRIMARY KEY (id));
>>>
>>> CREATE TABLE enum_value (id BIGSERIAL NOT NULL, StringEnum
>>> VARCHAR(10), ENUMHOLDER_ID BIGINT, PRIMARY KEY (id));
>>>
>>> package com.jpa.test;
>>>
>>> import javax.persistence.*;
>>> import java.util.*;
>>>
>>> @Entity
>>> @Table (name="enum_holder")
>>> public class EnumHolder
>>> implements java.io.Serializable
>>> {
>>> @GeneratedValue(strategy=GenerationType.IDENTITY)
>>> @Id private long id;
>>>
>>> @OrderBy
>>> @OneToMany(mappedBy="enumHolder", fetch=FetchType.LAZY,
>>> cascade={CascadeType.PERSIST,CascadeType.REMOVE})
>>> private Set<EnumValue> enums;
>>>
>>> public Set<EnumValue> getEnums()
>>> {
>>> if (enums == null)
>>> enums = new HashSet<EnumValue>();
>>> return enums;
>>> }
>>> }
>>>
>>> package com.jpa.test;
>>>
>>> import javax.persistence.*;
>>>
>>> @Entity
>>> @Table (name="enum_value")
>>> public class EnumValue
>>> implements java.io.Serializable
>>> {
>>> public static enum MyEnum{foo, Bar, Batz, woohoo}
>>>
>>> @GeneratedValue(strategy=GenerationType.IDENTITY)
>>> @Id private long id;
>>>
>>> @ManyToOne (optional=false, fetch=FetchType.LAZY,
>>> cascade=CascadeType.PERSIST)
>>> private EnumHolder enumHolder;
>>>
>>> @Enumerated (EnumType.STRING)
>>> @Column(name="StringEnum", length=10)
>>> private MyEnum myEnum;
>>>
>>> public MyEnum getMyEnum() { return myEnum; }
>>> }
>>>
>>>
>>>
>>> On 3/30/2009 9:47 AM, Tedman Leung wrote:
>>>
>>>>> How does your original example of ManyToMany annotation on a
>>>>> Collection of Enums actually work? My understanding is that for
>>>>> ManyToMany both sides must be persistent Entities. So therefore
>>>>> the ManyToMany is mapping the join table, not the Enum.
>>>>>
>>>> yes oddly enough it actually does work. As per my subsequent email,
>>>> I switched it to @PersistentCollection and it performed the same
>>>> way. I considered trying to annotate my Enum like an Entity but I
>>>> figured that would be pushing expected behaviour... even if it
>>>> worked, so I decided not to.
>>>>
>>>>
>>>>
>>>>> Isn't the same thing true that OneToMany should annotate a
>>>>> Collection of Entities? So the Enums would be a field on the
>>>>> ManyToOne side of that kind of mapping. Then you can specify
>>>>> the @Column and @Enumerated annotations on the actual field or
>>>>> property.
>>>>>
>>>> no you can't, I tried it. I can't remember the specific error but
>>>> it was along the lines of - you're not allowed to specify a column
>>>> attribute here.
>>>>
>>>>
>>>>> Could you explain why using the @PersistentCollection annotation
>>>>> is useful or necessary for OneToMany or ManyToMany collections
>>>>> generally or specifically in the case you are looking at? I
>>>>> don't understand the use case that @PersistentCollection
>>>>> satisfies.
>>>>>
>>>> My understanding is @ManyToMany is a JPA standard and is only used
>>>> to map entity to entities.
>>>>
>>>> My understanding of @PersistentCollection is that is is an OpenJpa
>>>> extention which allows people to map Entity to java Primities.
>>>>
>>>> i.e.
>>>>
>>>> @Entity
>>>> class Bar
>>>> {
>>>> }
>>>>
>>>> @Entity
>>>> class Foo
>>>> {
>>>> @ManyToMany
>>>> HashSet<Bar> myBars=new HashSet<Bar>();
>>>>
>>>> @PersistentCollection
>>>> HashSet<String> myStrings=new HashSet<String>();
>>>> }
>>>>
>>>>
>>>> I guess there's a reason why the original JPA standard left out
>>>> primitives... it gets complicated fast.
>>>>
>>>>
>>>>
>>>>> - Paul
>>>>>
>>>>>
>>>>> On 3/29/2009 8:43 PM, Tedman Leung wrote:
>>>>>
>>>>>> Just to document more thoughts and findings.
>>>>>>
>>>>>> 1) I was using the wrong annotation, I should have been using
>>>>>> @PersistentCollection
>>>>>>
>>>>>> 2) this seems to be a more wide spread problem with defining
>>>>>> attributes to collections, i.e. - collection of enums needs to
>>>>>> have @Enumerated configurations
>>>>>> - collection of Dates needs to have @Temporal configurations
>>>>>> - even collection of Strings seems to be missing a
>>>>>> @Column(nullable=false, length=32) style annotation.
>>>>>>
>>>>>> I think the problem is much bigger and wide spread than I originaly though,
>>>>>> I don't think I'll be able to sort out a patch.
>>>>>>
>>>>>>
>>>>>> On Sun, Mar 29, 2009 at 07:55:06AM -0700, Tedman Leung wrote:
>>>>>>
>>>>>>> yes I know I can do manual hacks to get them stored the way I
>>>>>>> want to, but I was asking if there was a jpa / openjpa
>>>>>>> annotation to allow that.
>>>>>>>
>>>>>>> As an example, I can just use @Enumerated on a single enum,
>>>>>>> so it seems logical that some one would have thought about
>>>>>>> storing a collection of enums.
>>>>>>>
>>>>>>> As for why I want them as strings instead of ordinals - the
>>>>>>> usual reasons, i.e. it's safer for changes as the ordering
>>>>>>> won't accidentally corrupt my data (and without telling me),
>>>>>>> and it's easier to look into the database via sql or
>>>>>>> something and just know what's going on / get simple reports
>>>>>>> etc.
>>>>>>>
>>>>>>> I'm guessing right now that it's not possible at all and that
>>>>>>> no one has done anything towards this. I might have to
>>>>>>> rummage through the source and try to see if I can figure out
>>>>>>> how it works and hack a patch to submit. It seemed like a
>>>>>>> very straight forward use case though so I'm surprised no one
>>>>>>> has asked or done anything about this before.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
>>>>>>>
>>>>>>>> What is your objective? Do you want some non-JPA
>>>>>>>> application to see them in the database as Strings?
>>>>>>>>
>>>>>>>> At some point you have add these Enums to the collection
>>>>>>>> one at a time. You can use an addEnum() method or an
>>>>>>>> Entity listener to convert them to Strings at that point
>>>>>>>> one at a time. And a subclass of the Collection type to
>>>>>>>> getEnum() from the Collection when you fetch them back.
>>>>>>>>
>>>>>>>> new MyStringEnumHashSet<MyStringEnumType>()
>>>>>>>>
>>>>>>>> On 3/28/2009 9:27 PM, Tedman Leung wrote:
>>>>>>>>
>>>>>>>>> No, I'm talking about when the enum is in a collection.
>>>>>>>>>
>>>>>>>>> i.e.
>>>>>>>>>
>>>>>>>>> Private HashSet<Gender> genders=new HashSet<Gender>();
>>>>>>>>>
>>>>>>>>> So no, either the @Enumerated helps, nor does calling
>>>>>>>>> name() or toString as neither are possible.
>>>>>>>>>
>>>>>>>>> I'm storing a Collection of enums , not a single Enum.
>>>>>>>>>
>>>>>>>>> There seems to be no examples of this nor any
>>>>>>>>> documentation about the ability to do this that I can
>>>>>>>>> find. The default seems to use the ordinal value both for
>>>>>>>>> table generation and storage value.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>>>>>>>>>
>>>>>>>>>> Hi - This is from the OpenJPA relations example -
>>>>>>>>>>
>>>>>>>>>> @Basic @Enumerated(EnumType.STRING)
>>>>>>>>>> private Gender gender;
>>>>>>>>>>
>>>>>>>>>> public static enum Gender { MALE, FEMALE }
>>>>>>>>>>
>>>>>>>>>> public void setGender(Gender gender) {
>>>>>>>>>> this.gender = gender;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> See section 12.8.1.2 in the OpenJPA Overview
>>>>>>>>>>
>>>>>>>>>> - Paul
>>>>>>>>>>
>>>>>>>>>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>>>>>>>>>
>>>>>>>>>>> Ted,
>>>>>>>>>>> If you are using Java 5, then you could use name() or toString() API on the
>>>>>>>>>>> Enum to get the name of the enum constant in String value.
>>>>>>>>>>>
>>>>>>>>>>> Catalina
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>>>>>>>>>> ordinal values? (preferably with annotations...)
>>>>>>>>>>>>
>>>>>>>>>>>> i.e.
>>>>>>>>>>>> @ManyToMany
>>>>>>>>>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Ted Leung
>>>>>>>>>>>> tedman@sfu.ca
>>>>>>>>>>>>
>>>>>>>>>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>> Ted Leung
>>>>>>> tedman@sfu.ca
>>>>>>>
>>>>>>> The most important words I've learned to say - "I don't know".
>>>>>>>
>>>>>>
>>>>
>>
>>
>
--
Ted Leung
tedman@sfu.ca
The most important words I've learned to say - "I don't know".
Re: how to store collection of enums as strings
Posted by Paul Copeland <te...@jotobjects.com>.
Hi Ted -
Interesting point of view. I would have thought this is the plain
vanilla "simple clean out of the box" way to persist a Collection of
Enums or any other kind of collection.
This results in a bare minimum join with two tables and a foreign key
which is how a Collection maps into the world of relational databases
whether you are using straight JDBC or JPA or Hibernate or brand X ORM.
In the end you wind up with two database tables and two objects that
model the association.
- Paul
On 3/31/2009 7:40 AM, Tedman Leung wrote:
> thanks but I was hoping there was a simple clean out of the box style
> solution. Considering the code could/should have just been a single
> annotation to the collection, the work around looks like an awful lot of
> work for a framework which is suppose to reduce work.
>
> In the end, I just used raw JDBC in a nativeQuery. At least this way other
> developers can understand the code I've written and it's only actually
> about 15 lines of simple straight forward code.
>
> thanks.
>
>
> On Mon, Mar 30, 2009 at 11:16:52AM -0700, Paul Copeland wrote:
>
>> Hi Ted - See example code below
>>
>> On 3/30/2009 9:47 AM, Tedman Leung wrote:
>>
>>>> Isn't the same thing true that OneToMany should annotate a Collection
>>>> of Entities? So the Enums would be a field on the ManyToOne side of
>>>> that kind of mapping. Then you can specify the @Column and
>>>> @Enumerated annotations on the actual field or property.
>>>>
>>>>
>>> no you can't, I tried it. I can't remember the specific error but it
>>> was along the lines of - you're not allowed to specify a column
>>> attribute here.
>>>
>>>
>> Here is an example that uses the @Enumerated and @Column annotations on
>> a OneToMany relation.
>>
>> This stores a Set of Enums as String values. A similar example would
>> work for ManyToMany. The same approach can also be used with
>> Collections of Temporal values.
>>
>> There are two classes - an EnumHolder that holds the Collection and an
>> EnumValue that holds an Enum and stores it as a String. Here is the
>> MappingTool generated SQL (Postgres database). As you can see the Enum
>> is stored as a String VARCHAR(10).
>>
>> CREATE TABLE enum_holder (id BIGSERIAL NOT NULL, PRIMARY KEY (id));
>>
>> CREATE TABLE enum_value (id BIGSERIAL NOT NULL, StringEnum VARCHAR(10),
>> ENUMHOLDER_ID BIGINT, PRIMARY KEY (id));
>>
>> package com.jpa.test;
>>
>> import javax.persistence.*;
>> import java.util.*;
>>
>> @Entity
>> @Table (name="enum_holder")
>> public class EnumHolder
>> implements java.io.Serializable
>> {
>> @GeneratedValue(strategy=GenerationType.IDENTITY)
>> @Id private long id;
>>
>> @OrderBy
>> @OneToMany(mappedBy="enumHolder", fetch=FetchType.LAZY,
>> cascade={CascadeType.PERSIST,CascadeType.REMOVE})
>> private Set<EnumValue> enums;
>>
>> public Set<EnumValue> getEnums()
>> {
>> if (enums == null)
>> enums = new HashSet<EnumValue>();
>> return enums;
>> }
>> }
>>
>> package com.jpa.test;
>>
>> import javax.persistence.*;
>>
>> @Entity
>> @Table (name="enum_value")
>> public class EnumValue
>> implements java.io.Serializable
>> {
>> public static enum MyEnum{foo, Bar, Batz, woohoo}
>>
>> @GeneratedValue(strategy=GenerationType.IDENTITY)
>> @Id private long id;
>>
>> @ManyToOne (optional=false, fetch=FetchType.LAZY,
>> cascade=CascadeType.PERSIST)
>> private EnumHolder enumHolder;
>>
>> @Enumerated (EnumType.STRING)
>> @Column(name="StringEnum", length=10)
>> private MyEnum myEnum;
>>
>> public MyEnum getMyEnum() { return myEnum; }
>> }
>>
>>
>>
>> On 3/30/2009 9:47 AM, Tedman Leung wrote:
>>
>>>> How does your original example of ManyToMany annotation on a
>>>> Collection of Enums actually work? My understanding is that for
>>>> ManyToMany both sides must be persistent Entities. So therefore the
>>>> ManyToMany is mapping the join table, not the Enum.
>>>>
>>>>
>>> yes oddly enough it actually does work. As per my subsequent email, I
>>> switched it to @PersistentCollection and it performed the same way. I
>>> considered trying to annotate my Enum like an Entity but I figured that
>>> would be pushing expected behaviour... even if it worked, so I decided
>>> not to.
>>>
>>>
>>>
>>>
>>>> Isn't the same thing true that OneToMany should annotate a Collection
>>>> of Entities? So the Enums would be a field on the ManyToOne side of
>>>> that kind of mapping. Then you can specify the @Column and
>>>> @Enumerated annotations on the actual field or property.
>>>>
>>>>
>>> no you can't, I tried it. I can't remember the specific error but it
>>> was along the lines of - you're not allowed to specify a column
>>> attribute here.
>>>
>>>
>>>
>>>> Could you explain why using the @PersistentCollection annotation is
>>>> useful or necessary for OneToMany or ManyToMany collections generally
>>>> or specifically in the case you are looking at? I don't understand
>>>> the use case that @PersistentCollection satisfies.
>>>>
>>>>
>>> My understanding is @ManyToMany is a JPA standard and is only used to
>>> map entity to entities.
>>>
>>> My understanding of @PersistentCollection is that is is an OpenJpa
>>> extention which allows people to map Entity to java Primities.
>>>
>>> i.e.
>>>
>>> @Entity
>>> class Bar
>>> {
>>> }
>>>
>>> @Entity
>>> class Foo
>>> {
>>> @ManyToMany
>>> HashSet<Bar> myBars=new HashSet<Bar>();
>>>
>>> @PersistentCollection
>>> HashSet<String> myStrings=new HashSet<String>();
>>> }
>>>
>>>
>>> I guess there's a reason why the original JPA standard left out
>>> primitives... it gets complicated fast.
>>>
>>>
>>>
>>>
>>>> - Paul
>>>>
>>>>
>>>> On 3/29/2009 8:43 PM, Tedman Leung wrote:
>>>>
>>>>
>>>>> Just to document more thoughts and findings.
>>>>>
>>>>> 1) I was using the wrong annotation, I should have been using
>>>>> @PersistentCollection
>>>>>
>>>>> 2) this seems to be a more wide spread problem with defining
>>>>> attributes to collections, i.e. - collection of enums needs to have
>>>>> @Enumerated configurations
>>>>> - collection of Dates needs to have @Temporal configurations
>>>>> - even collection of Strings seems to be missing a
>>>>> @Column(nullable=false, length=32) style annotation.
>>>>>
>>>>> I think the problem is much bigger and wide spread than I originaly though,
>>>>> I don't think I'll be able to sort out a patch.
>>>>>
>>>>>
>>>>> On Sun, Mar 29, 2009 at 07:55:06AM -0700, Tedman Leung wrote:
>>>>>
>>>>>
>>>>>> yes I know I can do manual hacks to get them stored the way I
>>>>>> want to, but I was asking if there was a jpa / openjpa annotation
>>>>>> to allow that.
>>>>>>
>>>>>> As an example, I can just use @Enumerated on a single enum, so it
>>>>>> seems logical that some one would have thought about storing a
>>>>>> collection of enums.
>>>>>>
>>>>>> As for why I want them as strings instead of ordinals - the usual
>>>>>> reasons, i.e. it's safer for changes as the ordering won't
>>>>>> accidentally corrupt my data (and without telling me), and it's
>>>>>> easier to look into the database via sql or something and just
>>>>>> know what's going on / get simple reports etc.
>>>>>>
>>>>>> I'm guessing right now that it's not possible at all and that no
>>>>>> one has done anything towards this. I might have to rummage
>>>>>> through the source and try to see if I can figure out how it
>>>>>> works and hack a patch to submit. It seemed like a very straight
>>>>>> forward use case though so I'm surprised no one has asked or done
>>>>>> anything about this before.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
>>>>>>
>>>>>>
>>>>>>> What is your objective? Do you want some non-JPA application
>>>>>>> to see them in the database as Strings?
>>>>>>>
>>>>>>> At some point you have add these Enums to the collection one at
>>>>>>> a time. You can use an addEnum() method or an Entity listener
>>>>>>> to convert them to Strings at that point one at a time. And a
>>>>>>> subclass of the Collection type to getEnum() from the
>>>>>>> Collection when you fetch them back.
>>>>>>>
>>>>>>> new MyStringEnumHashSet<MyStringEnumType>()
>>>>>>>
>>>>>>> On 3/28/2009 9:27 PM, Tedman Leung wrote:
>>>>>>>
>>>>>>>
>>>>>>>> No, I'm talking about when the enum is in a collection.
>>>>>>>>
>>>>>>>> i.e.
>>>>>>>>
>>>>>>>> Private HashSet<Gender> genders=new HashSet<Gender>();
>>>>>>>>
>>>>>>>> So no, either the @Enumerated helps, nor does calling name()
>>>>>>>> or toString as neither are possible.
>>>>>>>>
>>>>>>>> I'm storing a Collection of enums , not a single Enum.
>>>>>>>>
>>>>>>>> There seems to be no examples of this nor any documentation
>>>>>>>> about the ability to do this that I can find. The default
>>>>>>>> seems to use the ordinal value both for table generation and
>>>>>>>> storage value.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi - This is from the OpenJPA relations example -
>>>>>>>>>
>>>>>>>>> @Basic @Enumerated(EnumType.STRING)
>>>>>>>>> private Gender gender;
>>>>>>>>>
>>>>>>>>> public static enum Gender { MALE, FEMALE }
>>>>>>>>>
>>>>>>>>> public void setGender(Gender gender) {
>>>>>>>>> this.gender = gender;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> See section 12.8.1.2 in the OpenJPA Overview
>>>>>>>>>
>>>>>>>>> - Paul
>>>>>>>>>
>>>>>>>>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Ted,
>>>>>>>>>> If you are using Java 5, then you could use name() or toString() API on the
>>>>>>>>>> Enum to get the name of the enum constant in String value.
>>>>>>>>>>
>>>>>>>>>> Catalina
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>>>>>>>>> ordinal values? (preferably with annotations...)
>>>>>>>>>>>
>>>>>>>>>>> i.e.
>>>>>>>>>>> @ManyToMany
>>>>>>>>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ted Leung
>>>>>>>>>>> tedman@sfu.ca
>>>>>>>>>>>
>>>>>>>>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Ted Leung
>>>>>> tedman@sfu.ca
>>>>>>
>>>>>> The most important words I've learned to say - "I don't know".
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
thanks but I was hoping there was a simple clean out of the box style
solution. Considering the code could/should have just been a single
annotation to the collection, the work around looks like an awful lot of
work for a framework which is suppose to reduce work.
In the end, I just used raw JDBC in a nativeQuery. At least this way other
developers can understand the code I've written and it's only actually
about 15 lines of simple straight forward code.
thanks.
On Mon, Mar 30, 2009 at 11:16:52AM -0700, Paul Copeland wrote:
> Hi Ted - See example code below
>
> On 3/30/2009 9:47 AM, Tedman Leung wrote:
>>> Isn't the same thing true that OneToMany should annotate a Collection
>>> of Entities? So the Enums would be a field on the ManyToOne side of
>>> that kind of mapping. Then you can specify the @Column and
>>> @Enumerated annotations on the actual field or property.
>>>
>>
>> no you can't, I tried it. I can't remember the specific error but it
>> was along the lines of - you're not allowed to specify a column
>> attribute here.
>>
>
> Here is an example that uses the @Enumerated and @Column annotations on
> a OneToMany relation.
>
> This stores a Set of Enums as String values. A similar example would
> work for ManyToMany. The same approach can also be used with
> Collections of Temporal values.
>
> There are two classes - an EnumHolder that holds the Collection and an
> EnumValue that holds an Enum and stores it as a String. Here is the
> MappingTool generated SQL (Postgres database). As you can see the Enum
> is stored as a String VARCHAR(10).
>
> CREATE TABLE enum_holder (id BIGSERIAL NOT NULL, PRIMARY KEY (id));
>
> CREATE TABLE enum_value (id BIGSERIAL NOT NULL, StringEnum VARCHAR(10),
> ENUMHOLDER_ID BIGINT, PRIMARY KEY (id));
>
> package com.jpa.test;
>
> import javax.persistence.*;
> import java.util.*;
>
> @Entity
> @Table (name="enum_holder")
> public class EnumHolder
> implements java.io.Serializable
> {
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Id private long id;
>
> @OrderBy
> @OneToMany(mappedBy="enumHolder", fetch=FetchType.LAZY,
> cascade={CascadeType.PERSIST,CascadeType.REMOVE})
> private Set<EnumValue> enums;
>
> public Set<EnumValue> getEnums()
> {
> if (enums == null)
> enums = new HashSet<EnumValue>();
> return enums;
> }
> }
>
> package com.jpa.test;
>
> import javax.persistence.*;
>
> @Entity
> @Table (name="enum_value")
> public class EnumValue
> implements java.io.Serializable
> {
> public static enum MyEnum{foo, Bar, Batz, woohoo}
>
> @GeneratedValue(strategy=GenerationType.IDENTITY)
> @Id private long id;
>
> @ManyToOne (optional=false, fetch=FetchType.LAZY,
> cascade=CascadeType.PERSIST)
> private EnumHolder enumHolder;
>
> @Enumerated (EnumType.STRING)
> @Column(name="StringEnum", length=10)
> private MyEnum myEnum;
>
> public MyEnum getMyEnum() { return myEnum; }
> }
>
>
>
> On 3/30/2009 9:47 AM, Tedman Leung wrote:
>>> How does your original example of ManyToMany annotation on a
>>> Collection of Enums actually work? My understanding is that for
>>> ManyToMany both sides must be persistent Entities. So therefore the
>>> ManyToMany is mapping the join table, not the Enum.
>>>
>>
>> yes oddly enough it actually does work. As per my subsequent email, I
>> switched it to @PersistentCollection and it performed the same way. I
>> considered trying to annotate my Enum like an Entity but I figured that
>> would be pushing expected behaviour... even if it worked, so I decided
>> not to.
>>
>>
>>
>>> Isn't the same thing true that OneToMany should annotate a Collection
>>> of Entities? So the Enums would be a field on the ManyToOne side of
>>> that kind of mapping. Then you can specify the @Column and
>>> @Enumerated annotations on the actual field or property.
>>>
>>
>> no you can't, I tried it. I can't remember the specific error but it
>> was along the lines of - you're not allowed to specify a column
>> attribute here.
>>
>>
>>> Could you explain why using the @PersistentCollection annotation is
>>> useful or necessary for OneToMany or ManyToMany collections generally
>>> or specifically in the case you are looking at? I don't understand
>>> the use case that @PersistentCollection satisfies.
>>>
>>
>> My understanding is @ManyToMany is a JPA standard and is only used to
>> map entity to entities.
>>
>> My understanding of @PersistentCollection is that is is an OpenJpa
>> extention which allows people to map Entity to java Primities.
>>
>> i.e.
>>
>> @Entity
>> class Bar
>> {
>> }
>>
>> @Entity
>> class Foo
>> {
>> @ManyToMany
>> HashSet<Bar> myBars=new HashSet<Bar>();
>>
>> @PersistentCollection
>> HashSet<String> myStrings=new HashSet<String>();
>> }
>>
>>
>> I guess there's a reason why the original JPA standard left out
>> primitives... it gets complicated fast.
>>
>>
>>
>>> - Paul
>>>
>>>
>>> On 3/29/2009 8:43 PM, Tedman Leung wrote:
>>>
>>>> Just to document more thoughts and findings.
>>>>
>>>> 1) I was using the wrong annotation, I should have been using
>>>> @PersistentCollection
>>>>
>>>> 2) this seems to be a more wide spread problem with defining
>>>> attributes to collections, i.e. - collection of enums needs to have
>>>> @Enumerated configurations
>>>> - collection of Dates needs to have @Temporal configurations
>>>> - even collection of Strings seems to be missing a
>>>> @Column(nullable=false, length=32) style annotation.
>>>>
>>>> I think the problem is much bigger and wide spread than I originaly though,
>>>> I don't think I'll be able to sort out a patch.
>>>>
>>>>
>>>> On Sun, Mar 29, 2009 at 07:55:06AM -0700, Tedman Leung wrote:
>>>>
>>>>> yes I know I can do manual hacks to get them stored the way I
>>>>> want to, but I was asking if there was a jpa / openjpa annotation
>>>>> to allow that.
>>>>>
>>>>> As an example, I can just use @Enumerated on a single enum, so it
>>>>> seems logical that some one would have thought about storing a
>>>>> collection of enums.
>>>>>
>>>>> As for why I want them as strings instead of ordinals - the usual
>>>>> reasons, i.e. it's safer for changes as the ordering won't
>>>>> accidentally corrupt my data (and without telling me), and it's
>>>>> easier to look into the database via sql or something and just
>>>>> know what's going on / get simple reports etc.
>>>>>
>>>>> I'm guessing right now that it's not possible at all and that no
>>>>> one has done anything towards this. I might have to rummage
>>>>> through the source and try to see if I can figure out how it
>>>>> works and hack a patch to submit. It seemed like a very straight
>>>>> forward use case though so I'm surprised no one has asked or done
>>>>> anything about this before.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
>>>>>
>>>>>> What is your objective? Do you want some non-JPA application
>>>>>> to see them in the database as Strings?
>>>>>>
>>>>>> At some point you have add these Enums to the collection one at
>>>>>> a time. You can use an addEnum() method or an Entity listener
>>>>>> to convert them to Strings at that point one at a time. And a
>>>>>> subclass of the Collection type to getEnum() from the
>>>>>> Collection when you fetch them back.
>>>>>>
>>>>>> new MyStringEnumHashSet<MyStringEnumType>()
>>>>>>
>>>>>> On 3/28/2009 9:27 PM, Tedman Leung wrote:
>>>>>>
>>>>>>> No, I'm talking about when the enum is in a collection.
>>>>>>>
>>>>>>> i.e.
>>>>>>>
>>>>>>> Private HashSet<Gender> genders=new HashSet<Gender>();
>>>>>>>
>>>>>>> So no, either the @Enumerated helps, nor does calling name()
>>>>>>> or toString as neither are possible.
>>>>>>>
>>>>>>> I'm storing a Collection of enums , not a single Enum.
>>>>>>>
>>>>>>> There seems to be no examples of this nor any documentation
>>>>>>> about the ability to do this that I can find. The default
>>>>>>> seems to use the ordinal value both for table generation and
>>>>>>> storage value.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>>>>>>>
>>>>>>>> Hi - This is from the OpenJPA relations example -
>>>>>>>>
>>>>>>>> @Basic @Enumerated(EnumType.STRING)
>>>>>>>> private Gender gender;
>>>>>>>>
>>>>>>>> public static enum Gender { MALE, FEMALE }
>>>>>>>>
>>>>>>>> public void setGender(Gender gender) {
>>>>>>>> this.gender = gender;
>>>>>>>> }
>>>>>>>>
>>>>>>>> See section 12.8.1.2 in the OpenJPA Overview
>>>>>>>>
>>>>>>>> - Paul
>>>>>>>>
>>>>>>>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>>>>>>>
>>>>>>>>> Ted,
>>>>>>>>> If you are using Java 5, then you could use name() or toString() API on the
>>>>>>>>> Enum to get the name of the enum constant in String value.
>>>>>>>>>
>>>>>>>>> Catalina
>>>>>>>>>
>>>>>>>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>>>>>>>> ordinal values? (preferably with annotations...)
>>>>>>>>>>
>>>>>>>>>> i.e.
>>>>>>>>>> @ManyToMany
>>>>>>>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ted Leung
>>>>>>>>>> tedman@sfu.ca
>>>>>>>>>>
>>>>>>>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>> --
>>>>> Ted Leung
>>>>> tedman@sfu.ca
>>>>>
>>>>> The most important words I've learned to say - "I don't know".
>>>>>
>>>>
>>
>>
>
--
Ted Leung
tedman@sfu.ca
Being normal is vastly over rated.
Re: how to store collection of enums as strings
Posted by Paul Copeland <te...@jotobjects.com>.
Hi Ted - See example code below
On 3/30/2009 9:47 AM, Tedman Leung wrote:
>> Isn't the same thing true that OneToMany should annotate a Collection of
>> Entities? So the Enums would be a field on the ManyToOne side of that
>> kind of mapping. Then you can specify the @Column and @Enumerated
>> annotations on the actual field or property.
>>
>
> no you can't, I tried it. I can't remember the specific error but it was
> along the lines of - you're not allowed to specify a column attribute
> here.
>
Here is an example that uses the @Enumerated and @Column annotations on
a OneToMany relation.
This stores a Set of Enums as String values. A similar example would
work for ManyToMany. The same approach can also be used with
Collections of Temporal values.
There are two classes - an EnumHolder that holds the Collection and an
EnumValue that holds an Enum and stores it as a String. Here is the
MappingTool generated SQL (Postgres database). As you can see the Enum
is stored as a String VARCHAR(10).
CREATE TABLE enum_holder (id BIGSERIAL NOT NULL, PRIMARY KEY (id));
CREATE TABLE enum_value (id BIGSERIAL NOT NULL, StringEnum VARCHAR(10),
ENUMHOLDER_ID BIGINT, PRIMARY KEY (id));
package com.jpa.test;
import javax.persistence.*;
import java.util.*;
@Entity
@Table (name="enum_holder")
public class EnumHolder
implements java.io.Serializable
{
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Id private long id;
@OrderBy
@OneToMany(mappedBy="enumHolder", fetch=FetchType.LAZY,
cascade={CascadeType.PERSIST,CascadeType.REMOVE})
private Set<EnumValue> enums;
public Set<EnumValue> getEnums()
{
if (enums == null)
enums = new HashSet<EnumValue>();
return enums;
}
}
package com.jpa.test;
import javax.persistence.*;
@Entity
@Table (name="enum_value")
public class EnumValue
implements java.io.Serializable
{
public static enum MyEnum{foo, Bar, Batz, woohoo}
@GeneratedValue(strategy=GenerationType.IDENTITY)
@Id private long id;
@ManyToOne (optional=false, fetch=FetchType.LAZY,
cascade=CascadeType.PERSIST)
private EnumHolder enumHolder;
@Enumerated (EnumType.STRING)
@Column(name="StringEnum", length=10)
private MyEnum myEnum;
public MyEnum getMyEnum() { return myEnum; }
}
On 3/30/2009 9:47 AM, Tedman Leung wrote:
>> How does your original example of ManyToMany annotation on a Collection
>> of Enums actually work? My understanding is that for ManyToMany both
>> sides must be persistent Entities. So therefore the ManyToMany is
>> mapping the join table, not the Enum.
>>
>
> yes oddly enough it actually does work. As per my subsequent email, I
> switched it to @PersistentCollection and it performed the same way. I
> considered trying to annotate my Enum like an Entity but I figured that
> would be pushing expected behaviour... even if it worked, so I decided not
> to.
>
>
>
>> Isn't the same thing true that OneToMany should annotate a Collection of
>> Entities? So the Enums would be a field on the ManyToOne side of that
>> kind of mapping. Then you can specify the @Column and @Enumerated
>> annotations on the actual field or property.
>>
>
> no you can't, I tried it. I can't remember the specific error but it was
> along the lines of - you're not allowed to specify a column attribute
> here.
>
>
>> Could you explain why using the @PersistentCollection annotation is
>> useful or necessary for OneToMany or ManyToMany collections generally or
>> specifically in the case you are looking at? I don't understand the use
>> case that @PersistentCollection satisfies.
>>
>
> My understanding is @ManyToMany is a JPA standard and is only used to map
> entity to entities.
>
> My understanding of @PersistentCollection is that is is an OpenJpa
> extention which allows people to map Entity to java Primities.
>
> i.e.
>
> @Entity
> class Bar
> {
> }
>
> @Entity
> class Foo
> {
> @ManyToMany
> HashSet<Bar> myBars=new HashSet<Bar>();
>
> @PersistentCollection
> HashSet<String> myStrings=new HashSet<String>();
> }
>
>
> I guess there's a reason why the original JPA standard left out
> primitives... it gets complicated fast.
>
>
>
>> - Paul
>>
>>
>> On 3/29/2009 8:43 PM, Tedman Leung wrote:
>>
>>> Just to document more thoughts and findings.
>>>
>>> 1) I was using the wrong annotation, I should have been using
>>> @PersistentCollection
>>>
>>> 2) this seems to be a more wide spread problem with defining
>>> attributes to collections, i.e. - collection of enums needs to have
>>> @Enumerated configurations
>>> - collection of Dates needs to have @Temporal configurations
>>> - even collection of Strings seems to be missing a
>>> @Column(nullable=false, length=32) style annotation.
>>>
>>> I think the problem is much bigger and wide spread than I originaly though,
>>> I don't think I'll be able to sort out a patch.
>>>
>>>
>>> On Sun, Mar 29, 2009 at 07:55:06AM -0700, Tedman Leung wrote:
>>>
>>>
>>>> yes I know I can do manual hacks to get them stored the way I want
>>>> to, but I was asking if there was a jpa / openjpa annotation to allow
>>>> that.
>>>>
>>>> As an example, I can just use @Enumerated on a single enum, so it
>>>> seems logical that some one would have thought about storing a
>>>> collection of enums.
>>>>
>>>> As for why I want them as strings instead of ordinals - the usual
>>>> reasons, i.e. it's safer for changes as the ordering won't
>>>> accidentally corrupt my data (and without telling me), and it's
>>>> easier to look into the database via sql or something and just know
>>>> what's going on / get simple reports etc.
>>>>
>>>> I'm guessing right now that it's not possible at all and that no one
>>>> has done anything towards this. I might have to rummage through the
>>>> source and try to see if I can figure out how it works and hack a
>>>> patch to submit. It seemed like a very straight forward use case
>>>> though so I'm surprised no one has asked or done anything about this
>>>> before.
>>>>
>>>>
>>>>
>>>> On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
>>>>
>>>>
>>>>> What is your objective? Do you want some non-JPA application to
>>>>> see them in the database as Strings?
>>>>>
>>>>> At some point you have add these Enums to the collection one at a
>>>>> time. You can use an addEnum() method or an Entity listener to
>>>>> convert them to Strings at that point one at a time. And a
>>>>> subclass of the Collection type to getEnum() from the Collection
>>>>> when you fetch them back.
>>>>>
>>>>> new MyStringEnumHashSet<MyStringEnumType>()
>>>>>
>>>>> On 3/28/2009 9:27 PM, Tedman Leung wrote:
>>>>>
>>>>>
>>>>>> No, I'm talking about when the enum is in a collection.
>>>>>>
>>>>>> i.e.
>>>>>>
>>>>>> Private HashSet<Gender> genders=new HashSet<Gender>();
>>>>>>
>>>>>> So no, either the @Enumerated helps, nor does calling name() or
>>>>>> toString as neither are possible.
>>>>>>
>>>>>> I'm storing a Collection of enums , not a single Enum.
>>>>>>
>>>>>> There seems to be no examples of this nor any documentation about
>>>>>> the ability to do this that I can find. The default seems to use
>>>>>> the ordinal value both for table generation and storage value.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>>>>>>
>>>>>>
>>>>>>> Hi - This is from the OpenJPA relations example -
>>>>>>>
>>>>>>> @Basic @Enumerated(EnumType.STRING)
>>>>>>> private Gender gender;
>>>>>>>
>>>>>>> public static enum Gender { MALE, FEMALE }
>>>>>>>
>>>>>>> public void setGender(Gender gender) {
>>>>>>> this.gender = gender;
>>>>>>> }
>>>>>>>
>>>>>>> See section 12.8.1.2 in the OpenJPA Overview
>>>>>>>
>>>>>>> - Paul
>>>>>>>
>>>>>>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Ted,
>>>>>>>> If you are using Java 5, then you could use name() or toString() API on the
>>>>>>>> Enum to get the name of the enum constant in String value.
>>>>>>>>
>>>>>>>> Catalina
>>>>>>>>
>>>>>>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>>>>>>> ordinal values? (preferably with annotations...)
>>>>>>>>>
>>>>>>>>> i.e.
>>>>>>>>> @ManyToMany
>>>>>>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ted Leung
>>>>>>>>> tedman@sfu.ca
>>>>>>>>>
>>>>>>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>> --
>>>> Ted Leung
>>>> tedman@sfu.ca
>>>>
>>>> The most important words I've learned to say - "I don't know".
>>>>
>>>>
>>>
>>>
>
>
Re: how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
> How does your original example of ManyToMany annotation on a Collection
> of Enums actually work? My understanding is that for ManyToMany both
> sides must be persistent Entities. So therefore the ManyToMany is
> mapping the join table, not the Enum.
yes oddly enough it actually does work. As per my subsequent email, I
switched it to @PersistentCollection and it performed the same way. I
considered trying to annotate my Enum like an Entity but I figured that
would be pushing expected behaviour... even if it worked, so I decided not
to.
> Isn't the same thing true that OneToMany should annotate a Collection of
> Entities? So the Enums would be a field on the ManyToOne side of that
> kind of mapping. Then you can specify the @Column and @Enumerated
> annotations on the actual field or property.
no you can't, I tried it. I can't remember the specific error but it was
along the lines of - you're not allowed to specify a column attribute
here.
> Could you explain why using the @PersistentCollection annotation is
> useful or necessary for OneToMany or ManyToMany collections generally or
> specifically in the case you are looking at? I don't understand the use
> case that @PersistentCollection satisfies.
My understanding is @ManyToMany is a JPA standard and is only used to map
entity to entities.
My understanding of @PersistentCollection is that is is an OpenJpa
extention which allows people to map Entity to java Primities.
i.e.
@Entity
class Bar
{
}
@Entity
class Foo
{
@ManyToMany
HashSet<Bar> myBars=new HashSet<Bar>();
@PersistentCollection
HashSet<String> myStrings=new HashSet<String>();
}
I guess there's a reason why the original JPA standard left out
primitives... it gets complicated fast.
> - Paul
>
>
> On 3/29/2009 8:43 PM, Tedman Leung wrote:
>> Just to document more thoughts and findings.
>>
>> 1) I was using the wrong annotation, I should have been using
>> @PersistentCollection
>>
>> 2) this seems to be a more wide spread problem with defining
>> attributes to collections, i.e. - collection of enums needs to have
>> @Enumerated configurations
>> - collection of Dates needs to have @Temporal configurations
>> - even collection of Strings seems to be missing a
>> @Column(nullable=false, length=32) style annotation.
>>
>> I think the problem is much bigger and wide spread than I originaly though,
>> I don't think I'll be able to sort out a patch.
>>
>>
>> On Sun, Mar 29, 2009 at 07:55:06AM -0700, Tedman Leung wrote:
>>
>>> yes I know I can do manual hacks to get them stored the way I want
>>> to, but I was asking if there was a jpa / openjpa annotation to allow
>>> that.
>>>
>>> As an example, I can just use @Enumerated on a single enum, so it
>>> seems logical that some one would have thought about storing a
>>> collection of enums.
>>>
>>> As for why I want them as strings instead of ordinals - the usual
>>> reasons, i.e. it's safer for changes as the ordering won't
>>> accidentally corrupt my data (and without telling me), and it's
>>> easier to look into the database via sql or something and just know
>>> what's going on / get simple reports etc.
>>>
>>> I'm guessing right now that it's not possible at all and that no one
>>> has done anything towards this. I might have to rummage through the
>>> source and try to see if I can figure out how it works and hack a
>>> patch to submit. It seemed like a very straight forward use case
>>> though so I'm surprised no one has asked or done anything about this
>>> before.
>>>
>>>
>>>
>>> On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
>>>
>>>> What is your objective? Do you want some non-JPA application to
>>>> see them in the database as Strings?
>>>>
>>>> At some point you have add these Enums to the collection one at a
>>>> time. You can use an addEnum() method or an Entity listener to
>>>> convert them to Strings at that point one at a time. And a
>>>> subclass of the Collection type to getEnum() from the Collection
>>>> when you fetch them back.
>>>>
>>>> new MyStringEnumHashSet<MyStringEnumType>()
>>>>
>>>> On 3/28/2009 9:27 PM, Tedman Leung wrote:
>>>>
>>>>> No, I'm talking about when the enum is in a collection.
>>>>>
>>>>> i.e.
>>>>>
>>>>> Private HashSet<Gender> genders=new HashSet<Gender>();
>>>>>
>>>>> So no, either the @Enumerated helps, nor does calling name() or
>>>>> toString as neither are possible.
>>>>>
>>>>> I'm storing a Collection of enums , not a single Enum.
>>>>>
>>>>> There seems to be no examples of this nor any documentation about
>>>>> the ability to do this that I can find. The default seems to use
>>>>> the ordinal value both for table generation and storage value.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>>>>>
>>>>>> Hi - This is from the OpenJPA relations example -
>>>>>>
>>>>>> @Basic @Enumerated(EnumType.STRING)
>>>>>> private Gender gender;
>>>>>>
>>>>>> public static enum Gender { MALE, FEMALE }
>>>>>>
>>>>>> public void setGender(Gender gender) {
>>>>>> this.gender = gender;
>>>>>> }
>>>>>>
>>>>>> See section 12.8.1.2 in the OpenJPA Overview
>>>>>>
>>>>>> - Paul
>>>>>>
>>>>>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>>>>>
>>>>>>> Ted,
>>>>>>> If you are using Java 5, then you could use name() or toString() API on the
>>>>>>> Enum to get the name of the enum constant in String value.
>>>>>>>
>>>>>>> Catalina
>>>>>>>
>>>>>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>>>>>> ordinal values? (preferably with annotations...)
>>>>>>>>
>>>>>>>> i.e.
>>>>>>>> @ManyToMany
>>>>>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ted Leung
>>>>>>>> tedman@sfu.ca
>>>>>>>>
>>>>>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>> --
>>> Ted Leung
>>> tedman@sfu.ca
>>>
>>> The most important words I've learned to say - "I don't know".
>>>
>>
>>
>
--
Ted Leung
tedman@sfu.ca
It's time for a new bike when the bulb in your shift light burns out.
Re: how to store collection of enums as strings
Posted by Paul Copeland <te...@jotobjects.com>.
Hi Ted - A few more questions to fill out my knowledge -
How does your original example of ManyToMany annotation on a Collection
of Enums actually work? My understanding is that for ManyToMany both
sides must be persistent Entities. So therefore the ManyToMany is
mapping the join table, not the Enum.
Isn't the same thing true that OneToMany should annotate a Collection of
Entities? So the Enums would be a field on the ManyToOne side of that
kind of mapping. Then you can specify the @Column and @Enumerated
annotations on the actual field or property.
Could you explain why using the @PersistentCollection annotation is
useful or necessary for OneToMany or ManyToMany collections generally or
specifically in the case you are looking at? I don't understand the use
case that @PersistentCollection satisfies.
- Paul
On 3/29/2009 8:43 PM, Tedman Leung wrote:
> Just to document more thoughts and findings.
>
> 1) I was using the wrong annotation, I should have been using
> @PersistentCollection
>
> 2) this seems to be a more wide spread problem with defining
> attributes to collections, i.e.
> - collection of enums needs to have @Enumerated configurations
> - collection of Dates needs to have @Temporal configurations
> - even collection of Strings seems to be missing a
> @Column(nullable=false, length=32) style annotation.
>
> I think the problem is much bigger and wide spread than I originaly though,
> I don't think I'll be able to sort out a patch.
>
>
> On Sun, Mar 29, 2009 at 07:55:06AM -0700, Tedman Leung wrote:
>
>> yes I know I can do manual hacks to get them stored the way I want to, but
>> I was asking if there was a jpa / openjpa annotation to allow that.
>>
>> As an example, I can just use @Enumerated on a single enum, so it seems
>> logical that some one would have thought about storing a collection of
>> enums.
>>
>> As for why I want them as strings instead of ordinals - the usual reasons,
>> i.e. it's safer for changes as the ordering won't accidentally corrupt my
>> data (and without telling me), and it's easier to look into the database
>> via sql or something and just know what's going on / get simple reports
>> etc.
>>
>> I'm guessing right now that it's not possible at all and that no one has
>> done anything towards this. I might have to rummage through the source
>> and try to see if I can figure out how it works and hack a patch to
>> submit. It seemed like a very straight forward use case though so I'm
>> surprised no one has asked or done anything about this before.
>>
>>
>>
>> On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
>>
>>> What is your objective? Do you want some non-JPA application to see
>>> them in the database as Strings?
>>>
>>> At some point you have add these Enums to the collection one at a time.
>>> You can use an addEnum() method or an Entity listener to convert them to
>>> Strings at that point one at a time. And a subclass of the Collection
>>> type to getEnum() from the Collection when you fetch them back.
>>>
>>> new MyStringEnumHashSet<MyStringEnumType>()
>>>
>>> On 3/28/2009 9:27 PM, Tedman Leung wrote:
>>>
>>>> No, I'm talking about when the enum is in a collection.
>>>>
>>>> i.e.
>>>>
>>>> Private HashSet<Gender> genders=new HashSet<Gender>();
>>>>
>>>> So no, either the @Enumerated helps, nor does calling name() or
>>>> toString as neither are possible.
>>>>
>>>> I'm storing a Collection of enums , not a single Enum.
>>>>
>>>> There seems to be no examples of this nor any documentation about the
>>>> ability to do this that I can find. The default seems to use the
>>>> ordinal value both for table generation and storage value.
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>>>>
>>>>
>>>>> Hi - This is from the OpenJPA relations example -
>>>>>
>>>>> @Basic @Enumerated(EnumType.STRING)
>>>>> private Gender gender;
>>>>>
>>>>> public static enum Gender { MALE, FEMALE }
>>>>>
>>>>> public void setGender(Gender gender) {
>>>>> this.gender = gender;
>>>>> }
>>>>>
>>>>> See section 12.8.1.2 in the OpenJPA Overview
>>>>>
>>>>> - Paul
>>>>>
>>>>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>>>>
>>>>>
>>>>>> Ted,
>>>>>> If you are using Java 5, then you could use name() or toString() API on the
>>>>>> Enum to get the name of the enum constant in String value.
>>>>>>
>>>>>> Catalina
>>>>>>
>>>>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>>>>> ordinal values? (preferably with annotations...)
>>>>>>>
>>>>>>> i.e.
>>>>>>> @ManyToMany
>>>>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ted Leung
>>>>>>> tedman@sfu.ca
>>>>>>>
>>>>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>> --
>> Ted Leung
>> tedman@sfu.ca
>>
>> The most important words I've learned to say - "I don't know".
>>
>
>
bug in @PersistentCollection(fetch=FetchType.EAGER)
Posted by Tedman Leung <te...@sfu.ca>.
I think I've found a bug in @PersistentCollection(fetch=FetchType.EAGER)
when used with Strings. It just doesn't seem to retrieve.
This only happens with FetchType.EAGER and it only happens if the entity
is being loaded from the database / not cached via openjpa.DataCache. (If
I create the entity then persist it, then do a find on it, it'll work, I
think it's because it's just hitting my cache, if I shutdown the jvm,
then start it up again, then load the entity I see the error.)
The declaration of the column is as follows :
@PersistentCollection(fetch=FetchType.EAGER)
@ContainerTable(name="UserRole", joinColumns=@XJoinColumn(name="userId", referencedColumnName="id"), joinForeignKey=@ForeignKey)
@ElementJoinColumn(name="Role")
private Set<String> roles=new HashSet<String>();
I'm using compile time enhancement.
I'm using java :
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode)
The openjpa is 1.2.1 as retrieved via the apache maven repositories.
The exception is as follows :
-----------------------------
Caused by: <openjpa-1.2.1-r752877:753278 nonfatal general error>
org.apache.openjpa.persistence.PersistenceException: java.lang.String
cannot be cast to org.apache.openjpa.enhance.PersistenceCapable
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:875)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:982)
at org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
at org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2400)
at org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:272)
at org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59)
at org.apache.openjpa.datacache.QueryCacheStoreQuery$CachingResultObjectProvider.getResultObject(QueryCacheStoreQuery.java:597)
at org.apache.openjpa.lib.rop.EagerResultList.<init>(EagerResultList.java:36)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1228)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:252)
at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:294)
--
Ted Leung
tedman@sfu.ca
It is easier to speak wisely than to act wisely.
Re: how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
Just to document more thoughts and findings.
1) I was using the wrong annotation, I should have been using
@PersistentCollection
2) this seems to be a more wide spread problem with defining
attributes to collections, i.e.
- collection of enums needs to have @Enumerated configurations
- collection of Dates needs to have @Temporal configurations
- even collection of Strings seems to be missing a
@Column(nullable=false, length=32) style annotation.
I think the problem is much bigger and wide spread than I originaly though,
I don't think I'll be able to sort out a patch.
On Sun, Mar 29, 2009 at 07:55:06AM -0700, Tedman Leung wrote:
> yes I know I can do manual hacks to get them stored the way I want to, but
> I was asking if there was a jpa / openjpa annotation to allow that.
>
> As an example, I can just use @Enumerated on a single enum, so it seems
> logical that some one would have thought about storing a collection of
> enums.
>
> As for why I want them as strings instead of ordinals - the usual reasons,
> i.e. it's safer for changes as the ordering won't accidentally corrupt my
> data (and without telling me), and it's easier to look into the database
> via sql or something and just know what's going on / get simple reports
> etc.
>
> I'm guessing right now that it's not possible at all and that no one has
> done anything towards this. I might have to rummage through the source
> and try to see if I can figure out how it works and hack a patch to
> submit. It seemed like a very straight forward use case though so I'm
> surprised no one has asked or done anything about this before.
>
>
>
> On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
> > What is your objective? Do you want some non-JPA application to see
> > them in the database as Strings?
> >
> > At some point you have add these Enums to the collection one at a time.
> > You can use an addEnum() method or an Entity listener to convert them to
> > Strings at that point one at a time. And a subclass of the Collection
> > type to getEnum() from the Collection when you fetch them back.
> >
> > new MyStringEnumHashSet<MyStringEnumType>()
> >
> > On 3/28/2009 9:27 PM, Tedman Leung wrote:
> >> No, I'm talking about when the enum is in a collection.
> >>
> >> i.e.
> >>
> >> Private HashSet<Gender> genders=new HashSet<Gender>();
> >>
> >> So no, either the @Enumerated helps, nor does calling name() or
> >> toString as neither are possible.
> >>
> >> I'm storing a Collection of enums , not a single Enum.
> >>
> >> There seems to be no examples of this nor any documentation about the
> >> ability to do this that I can find. The default seems to use the
> >> ordinal value both for table generation and storage value.
> >>
> >>
> >>
> >>
> >> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
> >>
> >>> Hi - This is from the OpenJPA relations example -
> >>>
> >>> @Basic @Enumerated(EnumType.STRING)
> >>> private Gender gender;
> >>>
> >>> public static enum Gender { MALE, FEMALE }
> >>>
> >>> public void setGender(Gender gender) {
> >>> this.gender = gender;
> >>> }
> >>>
> >>> See section 12.8.1.2 in the OpenJPA Overview
> >>>
> >>> - Paul
> >>>
> >>> On 3/28/2009 1:33 PM, catalina wei wrote:
> >>>
> >>>> Ted,
> >>>> If you are using Java 5, then you could use name() or toString() API on the
> >>>> Enum to get the name of the enum constant in String value.
> >>>>
> >>>> Catalina
> >>>>
> >>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
> >>>>
> >>>>
> >>>>> Anyone know how to store a collection of enums as Strings instead of their
> >>>>> ordinal values? (preferably with annotations...)
> >>>>>
> >>>>> i.e.
> >>>>> @ManyToMany
> >>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Ted Leung
> >>>>> tedman@sfu.ca
> >>>>>
> >>>>> It's time for a new bike when the bulb in your shift light burns out.
> >>>>>
> >>>>>
> >>>>
> >>
> >>
> >
>
> --
> Ted Leung
> tedman@sfu.ca
>
> The most important words I've learned to say - "I don't know".
--
Ted Leung
tedman@sfu.ca
It is easier to speak wisely than to act wisely.
Re: how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
yes I know I can do manual hacks to get them stored the way I want to, but
I was asking if there was a jpa / openjpa annotation to allow that.
As an example, I can just use @Enumerated on a single enum, so it seems
logical that some one would have thought about storing a collection of
enums.
As for why I want them as strings instead of ordinals - the usual reasons,
i.e. it's safer for changes as the ordering won't accidentally corrupt my
data (and without telling me), and it's easier to look into the database
via sql or something and just know what's going on / get simple reports
etc.
I'm guessing right now that it's not possible at all and that no one has
done anything towards this. I might have to rummage through the source
and try to see if I can figure out how it works and hack a patch to
submit. It seemed like a very straight forward use case though so I'm
surprised no one has asked or done anything about this before.
On Sat, Mar 28, 2009 at 10:13:16PM -0700, Paul Copeland wrote:
> What is your objective? Do you want some non-JPA application to see
> them in the database as Strings?
>
> At some point you have add these Enums to the collection one at a time.
> You can use an addEnum() method or an Entity listener to convert them to
> Strings at that point one at a time. And a subclass of the Collection
> type to getEnum() from the Collection when you fetch them back.
>
> new MyStringEnumHashSet<MyStringEnumType>()
>
> On 3/28/2009 9:27 PM, Tedman Leung wrote:
>> No, I'm talking about when the enum is in a collection.
>>
>> i.e.
>>
>> Private HashSet<Gender> genders=new HashSet<Gender>();
>>
>> So no, either the @Enumerated helps, nor does calling name() or
>> toString as neither are possible.
>>
>> I'm storing a Collection of enums , not a single Enum.
>>
>> There seems to be no examples of this nor any documentation about the
>> ability to do this that I can find. The default seems to use the
>> ordinal value both for table generation and storage value.
>>
>>
>>
>>
>> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>>
>>> Hi - This is from the OpenJPA relations example -
>>>
>>> @Basic @Enumerated(EnumType.STRING)
>>> private Gender gender;
>>>
>>> public static enum Gender { MALE, FEMALE }
>>>
>>> public void setGender(Gender gender) {
>>> this.gender = gender;
>>> }
>>>
>>> See section 12.8.1.2 in the OpenJPA Overview
>>>
>>> - Paul
>>>
>>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>>
>>>> Ted,
>>>> If you are using Java 5, then you could use name() or toString() API on the
>>>> Enum to get the name of the enum constant in String value.
>>>>
>>>> Catalina
>>>>
>>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>>
>>>>
>>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>>> ordinal values? (preferably with annotations...)
>>>>>
>>>>> i.e.
>>>>> @ManyToMany
>>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>>
>>>>>
>>>>> --
>>>>> Ted Leung
>>>>> tedman@sfu.ca
>>>>>
>>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>>
>>>>>
>>>>
>>
>>
>
--
Ted Leung
tedman@sfu.ca
The most important words I've learned to say - "I don't know".
Re: how to store collection of enums as strings
Posted by Paul Copeland <te...@jotobjects.com>.
What is your objective? Do you want some non-JPA application to see
them in the database as Strings?
At some point you have add these Enums to the collection one at a time.
You can use an addEnum() method or an Entity listener to convert them to
Strings at that point one at a time. And a subclass of the Collection
type to getEnum() from the Collection when you fetch them back.
new MyStringEnumHashSet<MyStringEnumType>()
On 3/28/2009 9:27 PM, Tedman Leung wrote:
> No, I'm talking about when the enum is in a collection.
>
> i.e.
>
> Private HashSet<Gender> genders=new HashSet<Gender>();
>
> So no, either the @Enumerated helps, nor does calling name() or toString
> as neither are possible.
>
> I'm storing a Collection of enums , not a single Enum.
>
> There seems to be no examples of this nor any documentation about the
> ability to do this that I can find. The default seems to use the ordinal
> value both for table generation and storage value.
>
>
>
>
> On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
>
>> Hi - This is from the OpenJPA relations example -
>>
>> @Basic @Enumerated(EnumType.STRING)
>> private Gender gender;
>>
>> public static enum Gender { MALE, FEMALE }
>>
>> public void setGender(Gender gender) {
>> this.gender = gender;
>> }
>>
>> See section 12.8.1.2 in the OpenJPA Overview
>>
>> - Paul
>>
>> On 3/28/2009 1:33 PM, catalina wei wrote:
>>
>>> Ted,
>>> If you are using Java 5, then you could use name() or toString() API on the
>>> Enum to get the name of the enum constant in String value.
>>>
>>> Catalina
>>>
>>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>>
>>>
>>>
>>>> Anyone know how to store a collection of enums as Strings instead of their
>>>> ordinal values? (preferably with annotations...)
>>>>
>>>> i.e.
>>>> @ManyToMany
>>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>>
>>>>
>>>> --
>>>> Ted Leung
>>>> tedman@sfu.ca
>>>>
>>>> It's time for a new bike when the bulb in your shift light burns out.
>>>>
>>>>
>>>>
>>>
>>>
>
>
Re: how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
No, I'm talking about when the enum is in a collection.
i.e.
Private HashSet<Gender> genders=new HashSet<Gender>();
So no, either the @Enumerated helps, nor does calling name() or toString
as neither are possible.
I'm storing a Collection of enums , not a single Enum.
There seems to be no examples of this nor any documentation about the
ability to do this that I can find. The default seems to use the ordinal
value both for table generation and storage value.
On Sat, Mar 28, 2009 at 01:56:13PM -0700, Paul Copeland wrote:
> Hi - This is from the OpenJPA relations example -
>
> @Basic @Enumerated(EnumType.STRING)
> private Gender gender;
>
> public static enum Gender { MALE, FEMALE }
>
> public void setGender(Gender gender) {
> this.gender = gender;
> }
>
> See section 12.8.1.2 in the OpenJPA Overview
>
> - Paul
>
> On 3/28/2009 1:33 PM, catalina wei wrote:
>> Ted,
>> If you are using Java 5, then you could use name() or toString() API on the
>> Enum to get the name of the enum constant in String value.
>>
>> Catalina
>>
>> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>
>>
>>> Anyone know how to store a collection of enums as Strings instead of their
>>> ordinal values? (preferably with annotations...)
>>>
>>> i.e.
>>> @ManyToMany
>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>
>>>
>>> --
>>> Ted Leung
>>> tedman@sfu.ca
>>>
>>> It's time for a new bike when the bulb in your shift light burns out.
>>>
>>>
>>
>>
>
--
Ted Leung
tedman@sfu.ca
// /*
You know things are getting a little fishy when you're commenting out
comments.
// */
Re: how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
yes! amazing!
@PersistentCollection(elementType=String.class)
@Externalizer("User.rolesToStrings")
@Factory("User.rolesFromStrings")
private HashSet<Role> testRoles=new HashSet<Role>();
works exactly like I want it to...
except that it also has problems with the eager fetching which I don't
quite understand. As a result I've resorted to sticking with my
nativeQuery work around. The eager fetching error is attached for anyone
who is really interested :
openjpa exception :
-------
Caused by: <openjpa-1.2.1-r752877:753278 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: java.lang.String cannot be cast to
org.apache.openjpa.enhance.PersistenceCapable
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:875)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:982)
at org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
at org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2400)
at org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:272)
at org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59)
at org.apache.openjpa.datacache.QueryCacheStoreQuery$CachingResultObjectProvider.getResultObject(QueryCacheStoreQuery.java:597)
at org.apache.openjpa.lib.rop.EagerResultList.<init>(EagerResultList.java:36)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1228)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:252)
at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:294)
... 26 more
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to org.apache.openjpa.enhance.PersistenceCapable
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setInverseRelation(JDBCStoreManager.java:408)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:380)
at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
at org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:352)
at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
... 59 more
On Tue, Mar 31, 2009 at 10:46:03AM -0500, Jody Grassel wrote:
> It sounds like you're trying to persist a collection of enumerations as a
> set of data and not as a reference to other entities, is that correct?
>
> If so, wouldn't a combination of @PersistentCollection and Externalization
> (section 6.6 in the manual) provide the function you are looking for?
>
>
> On Wed, Mar 25, 2009 at 11:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>
> > Anyone know how to store a collection of enums as Strings instead of their
> > ordinal values? (preferably with annotations...)
> >
> > i.e.
> > @ManyToMany
> > private Set<MyEnum> myEnums=new HashSet<MyEnum>();
> >
> >
> > --
> > Ted Leung
> > tedman@sfu.ca
> >
> > It's time for a new bike when the bulb in your shift light burns out.
> >
--
Ted Leung
tedman@sfu.ca
Being normal is vastly over rated.
Re: how to store collection of enums as strings
Posted by Jeremy Bauer <te...@gmail.com>.
Craig,
The latest public draft (3/13/2009) of the JPA 2.0 specification defines the
ability to apply the Enumeration (also Temporal and Lob) annotation to
element collection. Support within OpenJPA trunk will follow in the weeks
to come.
-Jeremy
On Tue, Mar 31, 2009 at 12:04 PM, Craig L Russell <Cr...@sun.com>wrote:
> I'd like to see a simple way to persist an EnumSet (which if I understand
> this use case is really what is desired):
>
> @Enumerated(STRING)
> @ElementCollection
> private EnumSet<MyEnum> myEnums = new EnumSet<MyEnum>();
>
> If no volunteers to implement this one (too bad it's not in the
> specification) then this would be my second choice:
>
> @Enumerated(STRING)
> @ElementCollection
> private Set<MyEnum> myEnums = new HashSet<MyEnum>();
>
> The @Enumerated tells us that you want the String value of the enum to be
> persisted (not the int value); the @ElementCollection tells us to persist
> the values individually and not as a serialized blob.
>
> Craig
>
>
> On Mar 31, 2009, at 8:46 AM, Jody Grassel wrote:
>
> It sounds like you're trying to persist a collection of enumerations as a
>> set of data and not as a reference to other entities, is that correct?
>>
>> If so, wouldn't a combination of @PersistentCollection and Externalization
>> (section 6.6 in the manual) provide the function you are looking for?
>>
>>
>> On Wed, Mar 25, 2009 at 11:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>>
>> Anyone know how to store a collection of enums as Strings instead of
>>> their
>>> ordinal values? (preferably with annotations...)
>>>
>>> i.e.
>>> @ManyToMany
>>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>>
>>>
>>> --
>>> Ted Leung
>>> tedman@sfu.ca
>>>
>>> It's time for a new bike when the bulb in your shift light burns out.
>>>
>>>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
Re: how to store collection of enums as strings
Posted by Craig L Russell <Cr...@Sun.COM>.
I'd like to see a simple way to persist an EnumSet (which if I
understand this use case is really what is desired):
@Enumerated(STRING)
@ElementCollection
private EnumSet<MyEnum> myEnums = new EnumSet<MyEnum>();
If no volunteers to implement this one (too bad it's not in the
specification) then this would be my second choice:
@Enumerated(STRING)
@ElementCollection
private Set<MyEnum> myEnums = new HashSet<MyEnum>();
The @Enumerated tells us that you want the String value of the enum to
be persisted (not the int value); the @ElementCollection tells us to
persist the values individually and not as a serialized blob.
Craig
On Mar 31, 2009, at 8:46 AM, Jody Grassel wrote:
> It sounds like you're trying to persist a collection of enumerations
> as a
> set of data and not as a reference to other entities, is that correct?
>
> If so, wouldn't a combination of @PersistentCollection and
> Externalization
> (section 6.6 in the manual) provide the function you are looking for?
>
>
> On Wed, Mar 25, 2009 at 11:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>
>> Anyone know how to store a collection of enums as Strings instead
>> of their
>> ordinal values? (preferably with annotations...)
>>
>> i.e.
>> @ManyToMany
>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>
>>
>> --
>> Ted Leung
>>
>> tedman@sfu.ca
>>
>> It's time for a new bike when the bulb in your shift light burns out.
>>
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: how to store collection of enums as strings
Posted by Jody Grassel <fy...@gmail.com>.
It sounds like you're trying to persist a collection of enumerations as a
set of data and not as a reference to other entities, is that correct?
If so, wouldn't a combination of @PersistentCollection and Externalization
(section 6.6 in the manual) provide the function you are looking for?
On Wed, Mar 25, 2009 at 11:48 AM, Tedman Leung <te...@sfu.ca> wrote:
> Anyone know how to store a collection of enums as Strings instead of their
> ordinal values? (preferably with annotations...)
>
> i.e.
> @ManyToMany
> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>
>
> --
> Ted Leung
> tedman@sfu.ca
>
> It's time for a new bike when the bulb in your shift light burns out.
>
Re: how to store collection of enums as strings
Posted by Paul Copeland <te...@jotobjects.com>.
Hi - This is from the OpenJPA relations example -
@Basic @Enumerated(EnumType.STRING)
private Gender gender;
public static enum Gender { MALE, FEMALE }
public void setGender(Gender gender) {
this.gender = gender;
}
See section 12.8.1.2 in the OpenJPA Overview
- Paul
On 3/28/2009 1:33 PM, catalina wei wrote:
> Ted,
> If you are using Java 5, then you could use name() or toString() API on the
> Enum to get the name of the enum constant in String value.
>
> Catalina
>
> On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
>
>
>> Anyone know how to store a collection of enums as Strings instead of their
>> ordinal values? (preferably with annotations...)
>>
>> i.e.
>> @ManyToMany
>> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>>
>>
>> --
>> Ted Leung
>> tedman@sfu.ca
>>
>> It's time for a new bike when the bulb in your shift light burns out.
>>
>>
>
>
Re: how to store collection of enums as strings
Posted by catalina wei <ca...@gmail.com>.
Ted,
If you are using Java 5, then you could use name() or toString() API on the
Enum to get the name of the enum constant in String value.
Catalina
On Wed, Mar 25, 2009 at 9:48 AM, Tedman Leung <te...@sfu.ca> wrote:
> Anyone know how to store a collection of enums as Strings instead of their
> ordinal values? (preferably with annotations...)
>
> i.e.
> @ManyToMany
> private Set<MyEnum> myEnums=new HashSet<MyEnum>();
>
>
> --
> Ted Leung
> tedman@sfu.ca
>
> It's time for a new bike when the bulb in your shift light burns out.
>
how to store collection of enums as strings
Posted by Tedman Leung <te...@sfu.ca>.
Anyone know how to store a collection of enums as Strings instead of their
ordinal values? (preferably with annotations...)
i.e.
@ManyToMany
private Set<MyEnum> myEnums=new HashSet<MyEnum>();
--
Ted Leung
tedman@sfu.ca
It's time for a new bike when the bulb in your shift light burns out.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Michael Dick <mi...@gmail.com>.
Hi Shubbis,
On Wed, Mar 25, 2009 at 9:51 AM, Shubbis <ma...@broadpark.no> wrote:
>
> Hi Michael,
>
> Sorry for the delay, but we have been very busy with the project and other
> mandatory school projects.
> Please don't mistake the delay for a lack of interest or enthusiasm.
>
> > Is the separate download the deciding factor or is it the experimentation
> > required to get the pool configured "right"? Including commons-dbcp in
> our
> > binary distribution is easy to fix. If it would help in bake-offs like
> this
> > I think we'd have no trouble getting the required votes for a change.
>
> Our project's guidelines specify that each framework has to be run with
> default functionality (or as close to as possible). For this specific
> project, with our guidelines, having dbcp included in the binary download
> would certainly allow it to be included.
>
> As you noted, this particular test doesn't benefit much from the pooling
> mechanism, but we are running quite a few other tests, so it would be
> interesting to include as much as possible.
>
I'll open a JIRA to include commons dbcp in the binary distribution. It
shouldn't increase the footprint too much.
As of right now though, it would seem that the procedure of opening new
> connections on every query was the culprit, and that ConnectionRetainMode
> has was the solution.
>
> I would like to ask though, if you could think of any reason a case like
> this would take much longer (5-10 sec) than say, EclipseLink to complete?
>
> Ex:
> Inserting a DeliveryCompany, with OneToOne relation to ContactInfo that has
> a ManyToOne to an Address that has an ManyToOne to an AreaCode that has a
> ManyToOne to a Country that has a ManyToOne to a Region.
>
> Now I realize that this is quite abstract, but I hope you get my point.
>
Nothing's jumping out at me. Might be an eager/lazy loading issue. Have you
specified any non-default loading properties in the entities, or are they
vanilla relationships?
>
> Shubbis
>
>
> Hi Shubbis,
>
> Glad to help. Some comments inline.
>
> On Sun, Mar 22, 2009 at 8:39 AM, Shubbis <ma...@broadpark.no>
> wrote:
>
> >
> > Hi Michael and everyone else involved!
> >
> > I greatly appreciate the efforts put into this and I'm glad to report
> that
> > simple testing at home, with the same laptop I use during the project, it
> > seems that i get the desired performance when enabling
> ConnectionRetainMode
> > = always. I will of course continue testing when i get back to the
> office.
> > Just to clarify, I'm not sure this is the end of all my worries ;)
> >
> > Note. I am running this without connection pooling as this was not a
> > default
> > setting of OpenJPA. The project specifies that all frameworks are run
> with
> > minimal setting changes and "as vanilla as possible".
> >
>
>
>
> > This does however not explain why i get much better results on my home
> > laptop. Granted it is faster and has more memory, but I got the same
> > results
> > as Pinaki which would indicate (to me atleast) that the result on my home
> > laptop is as it's "supposed" to be.
>
>
> I'm not sure why you're getting different results. Your initial results
> roughly matched mine so I went with them as a baseline. Maybe my laptop
> and
> your work system are equally performance challenged :-).
>
> Now, a question. Since this ConnectionRetainMode is not on always by
> > default. Does this suggest that OpenJPA is supposed/(required?) to be run
> > with a connection pool addon? I mean, if this was the case, why is it not
> > included by default?
> >
>
> I wouldn't say a connection pool is required any more than a L2 cache is
> required. It really depends on your use case. As you can tell when you run
> with RetainMode and no pool, adding a pool doesn't always help and it can
> lead to other interesting problems. Paul mentioned some in an earlier
> email.
> In addition OpenJPA is often used with a JEE Application Server, which
> typically provides its own connection pool. Having two levels of pooling
> can
> lead to some interesting problems.
>
> I suspect these are some of the reasons why OpenJPA was originally
> distributed without an integrated connection pool (and you don't have to go
> far to get commons-dbcp so why reinvent the wheel).
>
> This specific test really benefits from having a single connection to the
> database. There's only one thread using the DB, and it's just doing reads.
> As long as the use case doesn't change you won't see much benefit from a
> connection pool (you only need one connection anyway), or a L2 cache (the
> EM
> has cached everything for you). Try setting the connection pool size to 1
> for EclipseLink and OpenJPA and you might be surprised at the results.
>
> When you start writing data and have multiple EMs involved then your
> options
> become more intersting. Then you'll see benefits with a connection pool /
> L2
> cache, etc.
>
> I hope this made any sense, I'm having a hard time formulating coherent
> > replies as this is my second language and I'm quite new to all of this
> > (OpenJPA/JPA etc..).
> >
>
> You're doing better than I would do in my second language, I'm sure.
>
> -mike
>
>
> > Thanks again!
> >
> > Shubbis
> >
> >
> >
> > Michael Dick wrote:
> > >
> > > Hi all,
> > >
> > > As Paul pointed out privately I didn't indicate which versions of
> OpenJPA
> > > I
> > > was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT
> > > primarily.
> > > I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't
> > > much
> > > difference though so reduced the scope to 1.2 and trunk.
> > >
> > > The testcase uses a single EntityManager instance to issue a batch of
> > > findBy
> > > operations. In OpenJPA each findBy (or any query for that matter)
> obtains
> > > a
> > > connection from the connection pool and returns it after getting the
> > > results. So we're spending a lot of time moving the connection to and
> > from
> > > the pool (some cleanup is done along the way).
> > >
> > > Fortunately this behavior can be configured with the
> > > openjpa.ConnectionRetainMode property. Setting it to "always" causes
> the
> > > EntityManager to hold on to a single connection until the EntityManager
> > > closes. Obviously this setting introduces the possibility of exhausting
> > > the
> > > connection pool if num_entitymanagers > max_connections, but for this
> > > benchmark it's safe to try.
> > >
> > > Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop
> > at
> > > 100 - 100,000 iterations. In addition I removed the
> > > openjpa.jdbc.SynchronizeMappings property from the example (it's
> > > extraneous
> > > once the tables are created anyway).Another option I enabled that made
> > > some
> > > difference was preparedStatementCaching in dbcp. I'm assuming
> EclipseLink
> > > has some pstmt caching as well, but that could be faulty - in which
> case
> > > I'll disable it in dbcp.
> > >
> > > Here's the entire set of properties I'm using :
> > > properties.put("openjpa.Log", "DefaultLevel=FATAL");
> > > properties.put("openjpa.RuntimeUnenhancedClasses",
> > "unsupported");
> > > properties.put("openjpa.ConnectionRetainMode", "always");
> > > properties.put("openjpa.ConnectionDriverName",
> > > "org.apache.commons.dbcp.BasicDataSource");
> > >
> > > properties.put("openjpa.ConnectionProperties", String.format(
> > > "DriverClassName=%s, Url=%s, username=%s, password=%s,"
> > > + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
> > > + ", poolPreparedStatements=true"
> > > , JDBC_DRIVER, JDBC_URL, JDBC_USER,
> > > JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
> > >
> > > EntityManagerFactory factory =
> > > Persistence.createEntityManagerFactory("OpenJPAPU",
> > > properties);
> > >
> > > MIN_CON = 1, MAX_CON=10.
> > >
> > > Shubbis, could you try running something similar and see if you get the
> > > same
> > > results?
> > >
> > > -mike
> > >
> > > On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick
> > > <mi...@gmail.com>wrote:
> > >
> > >> Hi, I took a quick run with the source code from the RAR Shubbis
> > attached
> > >> earlier (thanks BTW).
> > >>
> > >> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
> > >> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt
> > >> EclipseLink
> > >> is doing better (certainly not 3x) based solely on the SQL.
> > >>
> > >> So I started digging deeper and on my laptop (not to be confused with
> > any
> > >> sort of "real" benchmark) there's a sweet spot around 100 iterations.
> > >> Under
> > >> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and
> over
> > >> 125
> > >> iterations EclipseLink starts pulling ahead.
> > >>
> > >> Environment :
> > >> * Entities were enhanced by the PCEnhancer tool prior to running the
> > >> tests.
> > >>
> > >> * Connection pooling is enabled for EclipseLink and OpenJPA with
> roughly
> > >> the same settings. EclipseLink's pool and commons-dbcp weren't an easy
> > >> 1:1
> > >> match, so I might have some investigation to do there.
> > >> * MySQL Connector for Java v 5.1.7.
> > >> * MySQL database running locally, Version: 5.0.67-0ubuntu6
> > >> * Tests executed in Eclipse, YMMV outside of Eclipse.
> > >> * Sun JDK 5 java full version "1.5.0_15-b04"
> > >>
> > >> I have done a lot of hacking about with the sample application but I
> > >> don't
> > >> think I've violated the intent of the exercise. I'll upload the app to
> a
> > >> jira shortly.
> > >>
> > >> The relevant code is in my pastebin at these links :
> > >> persistence.xml : http://miked.pastebin.com/m490814b7
> > >> test01.java : http://miked.pastebin.com/m7d3df62f
> > >> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
> > >>
> > >> I highlighted the changed lines in WarehouseDAO, but missed it on the
> > >> others (too many lines to highlight accurately.
> > >>
> > >> I'm still looking, but thought this was worth sharing in case someone
> > >> else
> > >> sees something I've missed.
> > >>
> > >> -mike
> > >>
> > >>
> > >>
> > >> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland
> > >> <te...@jotobjects.com>wrote:
> > >>
> > >>>
> > >>> At one point in this thread it was mentioned that the benchmark ran
> > much
> > >>> faster on a home computer than on an office computer and the reason
> for
> > >>> the
> > >>> difference was not obvious. Was that difference explained yet?
> > >>>
> > >>> What version of OpenJPA is the test using?
> > >>>
> > >>> - Paul
> > >>>
> > >>>
> > >>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
> > >>>
> > >>>> Shubbis and Nitish,
> > >>>> Thanks for your efforts. So, to clarify -- all implementations are
> > >>>> using
> > >>>> similar configurations (ie. connection pooling, caching,
> enhancement,
> > >>>> etc)?
> > >>>> But, the OpenJPA performance is still 3 times slower than the
> > >>>> competitors?
> > >>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
> > >>>> would
> > >>>> expect some overhead as compared to iBatis and/or straight JDBC, but
> > >>>> OpenJPA
> > >>>> should be competitive (and beat) the Hibernates and EclipseLinks...
> > >>>> Very
> > >>>> frustrating. When we do our comparisons with the industry
> benchmarks
> > >>>> (Trade
> > >>>> and SpecJApp), OpenJPA is extremely competitive.
> > >>>>
> > >>>> I have not closely examined your benchmark project, so I don't know
> > how
> > >>>> it
> > >>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
> > >>>> topic?
> > >>>>
> > >>>> One other thought... Just to prove that the enhancement processing
> is
> > >>>> being
> > >>>> done and you're not falling into the sub-classing support, could you
> > >>>> run
> > >>>> with the following property? This will cause your application to
> > >>>> error-off
> > >>>> if your Entities are not byte-code enhanced. We will not fall into
> > the
> > >>>> sub-classing support which greatly affects the performance.
> > >>>>
> > >>>> <property name="openjpa.RuntimeUnenhancedClasses"
> > >>>> value="warn"/>
> > >>>>
> > >>>> It really seems that you are trying to do a fair comparison, and I
> > >>>> greatly
> > >>>> appreciate your efforts. The last time one of these comparisons was
> > >>>> posted,
> > >>>> the benchmark code and process was flawed. So, I am pleased to see
> > the
> > >>>> efforts associated with this exercise.
> > >>>>
> > >>>> Our performance lead is out having a baby, so we haven't been able
> to
> > >>>> dig
> > >>>> into your benchmark to the extent that we would like. If we can
> > verify
> > >>>> that
> > >>>> the enhancement processing is happening, that would be good input.
> > >>>> Thanks
> > >>>> for your patience. What kind of timeframe are you under for posting
> > >>>> this
> > >>>> benchmark?
> > >>>>
> > >>>> Thanks,
> > >>>> Kevin
> > >>>>
> > >>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <marius.jones@broadpark.no
> >
> > >>>> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Since we decided to go with vanilla installations of alle the
> > >>>>> frameworks
> > >>>>> we
> > >>>>> have not added the connection pool feature to OpenJPA, until now.
> > >>>>>
> > >>>>> The results are sadly not that great. Yes, it's faster and it
> doesn't
> > >>>>> run
> > >>>>> out of connections like before, BUT it's still 3, yes, -three-
> times
> > >>>>> slower
> > >>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when
> persisting
> > >>>>> entities with many relations.
> > >>>>>
> > >>>>> Clearly this is not the kind of results I was hoping for and I'm
> > quite
> > >>>>> perplexed as to what to do.
> > >>>>>
> > >>>>> Shubbis
> > >>>>>
> > >>>>>
> > >>>>> Nitish Kumar wrote:
> > >>>>>
> > >>>>>
> > >>>>>> Hi subbis,
> > >>>>>> If I let the iteration loop over 5000, I get that exception,
> It
> > >>>>>> seems (I am not sure) openjpa is creating a new connection and
> after
> > >>>>>> a
> > >>>>>> while mysql runs out of connection. I tried the same code and
> > >>>>>> iteration
> > >>>>>> loop with a connection pool and it works fine. That should get you
> > >>>>>> moving as of now, till someone from Open JPA team looks into the
> > >>>>>> issue.
> > >>>>>>
> > >>>>>> Thanks and Regards,
> > >>>>>> Nitish Kumar
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>> --
> > >>>>> View this message in context:
> > >>>>>
> > >>>>>
> >
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
> > >>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >
> > >
> >
> > --
> > View this message in context:
> >
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2516988.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
> >
>
>
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2532837.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Hi Michael,
Sorry for the delay, but we have been very busy with the project and other mandatory school projects.
Please don't mistake the delay for a lack of interest or enthusiasm.
> Is the separate download the deciding factor or is it the experimentation
> required to get the pool configured "right"? Including commons-dbcp in our
> binary distribution is easy to fix. If it would help in bake-offs like this
> I think we'd have no trouble getting the required votes for a change.
Our project's guidelines specify that each framework has to be run with default functionality (or as close to as possible). For this specific project, with our guidelines, having dbcp included in the binary download would certainly allow it to be included.
As you noted, this particular test doesn't benefit much from the pooling mechanism, but we are running quite a few other tests, so it would be interesting to include as much as possible.
As of right now though, it would seem that the procedure of opening new connections on every query was the culprit, and that ConnectionRetainMode has was the solution.
I would like to ask though, if you could think of any reason a case like this would take much longer (5-10 sec) than say, EclipseLink to complete?
Ex:
Inserting a DeliveryCompany, with OneToOne relation to ContactInfo that has a ManyToOne to an Address that has an ManyToOne to an AreaCode that has a ManyToOne to a Country that has a ManyToOne to a Region.
Now I realize that this is quite abstract, but I hope you get my point.
Shubbis
Hi Shubbis,
Glad to help. Some comments inline.
On Sun, Mar 22, 2009 at 8:39 AM, Shubbis <ma...@broadpark.no> wrote:
>
> Hi Michael and everyone else involved!
>
> I greatly appreciate the efforts put into this and I'm glad to report that
> simple testing at home, with the same laptop I use during the project, it
> seems that i get the desired performance when enabling ConnectionRetainMode
> = always. I will of course continue testing when i get back to the office.
> Just to clarify, I'm not sure this is the end of all my worries ;)
>
> Note. I am running this without connection pooling as this was not a
> default
> setting of OpenJPA. The project specifies that all frameworks are run with
> minimal setting changes and "as vanilla as possible".
>
> This does however not explain why i get much better results on my home
> laptop. Granted it is faster and has more memory, but I got the same
> results
> as Pinaki which would indicate (to me atleast) that the result on my home
> laptop is as it's "supposed" to be.
I'm not sure why you're getting different results. Your initial results
roughly matched mine so I went with them as a baseline. Maybe my laptop and
your work system are equally performance challenged :-).
Now, a question. Since this ConnectionRetainMode is not on always by
> default. Does this suggest that OpenJPA is supposed/(required?) to be run
> with a connection pool addon? I mean, if this was the case, why is it not
> included by default?
>
I wouldn't say a connection pool is required any more than a L2 cache is
required. It really depends on your use case. As you can tell when you run
with RetainMode and no pool, adding a pool doesn't always help and it can
lead to other interesting problems. Paul mentioned some in an earlier email.
In addition OpenJPA is often used with a JEE Application Server, which
typically provides its own connection pool. Having two levels of pooling can
lead to some interesting problems.
I suspect these are some of the reasons why OpenJPA was originally
distributed without an integrated connection pool (and you don't have to go
far to get commons-dbcp so why reinvent the wheel).
This specific test really benefits from having a single connection to the
database. There's only one thread using the DB, and it's just doing reads.
As long as the use case doesn't change you won't see much benefit from a
connection pool (you only need one connection anyway), or a L2 cache (the EM
has cached everything for you). Try setting the connection pool size to 1
for EclipseLink and OpenJPA and you might be surprised at the results.
When you start writing data and have multiple EMs involved then your options
become more intersting. Then you'll see benefits with a connection pool / L2
cache, etc.
I hope this made any sense, I'm having a hard time formulating coherent
> replies as this is my second language and I'm quite new to all of this
> (OpenJPA/JPA etc..).
>
You're doing better than I would do in my second language, I'm sure.
-mike
> Thanks again!
>
> Shubbis
>
>
>
> Michael Dick wrote:
> >
> > Hi all,
> >
> > As Paul pointed out privately I didn't indicate which versions of OpenJPA
> > I
> > was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT
> > primarily.
> > I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't
> > much
> > difference though so reduced the scope to 1.2 and trunk.
> >
> > The testcase uses a single EntityManager instance to issue a batch of
> > findBy
> > operations. In OpenJPA each findBy (or any query for that matter) obtains
> > a
> > connection from the connection pool and returns it after getting the
> > results. So we're spending a lot of time moving the connection to and
> from
> > the pool (some cleanup is done along the way).
> >
> > Fortunately this behavior can be configured with the
> > openjpa.ConnectionRetainMode property. Setting it to "always" causes the
> > EntityManager to hold on to a single connection until the EntityManager
> > closes. Obviously this setting introduces the possibility of exhausting
> > the
> > connection pool if num_entitymanagers > max_connections, but for this
> > benchmark it's safe to try.
> >
> > Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop
> at
> > 100 - 100,000 iterations. In addition I removed the
> > openjpa.jdbc.SynchronizeMappings property from the example (it's
> > extraneous
> > once the tables are created anyway).Another option I enabled that made
> > some
> > difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
> > has some pstmt caching as well, but that could be faulty - in which case
> > I'll disable it in dbcp.
> >
> > Here's the entire set of properties I'm using :
> > properties.put("openjpa.Log", "DefaultLevel=FATAL");
> > properties.put("openjpa.RuntimeUnenhancedClasses",
> "unsupported");
> > properties.put("openjpa.ConnectionRetainMode", "always");
> > properties.put("openjpa.ConnectionDriverName",
> > "org.apache.commons.dbcp.BasicDataSource");
> >
> > properties.put("openjpa.ConnectionProperties", String.format(
> > "DriverClassName=%s, Url=%s, username=%s, password=%s,"
> > + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
> > + ", poolPreparedStatements=true"
> > , JDBC_DRIVER, JDBC_URL, JDBC_USER,
> > JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
> >
> > EntityManagerFactory factory =
> > Persistence.createEntityManagerFactory("OpenJPAPU",
> > properties);
> >
> > MIN_CON = 1, MAX_CON=10.
> >
> > Shubbis, could you try running something similar and see if you get the
> > same
> > results?
> >
> > -mike
> >
> > On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick
> > <mi...@gmail.com>wrote:
> >
> >> Hi, I took a quick run with the source code from the RAR Shubbis
> attached
> >> earlier (thanks BTW).
> >>
> >> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
> >> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt
> >> EclipseLink
> >> is doing better (certainly not 3x) based solely on the SQL.
> >>
> >> So I started digging deeper and on my laptop (not to be confused with
> any
> >> sort of "real" benchmark) there's a sweet spot around 100 iterations.
> >> Under
> >> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over
> >> 125
> >> iterations EclipseLink starts pulling ahead.
> >>
> >> Environment :
> >> * Entities were enhanced by the PCEnhancer tool prior to running the
> >> tests.
> >>
> >> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
> >> the same settings. EclipseLink's pool and commons-dbcp weren't an easy
> >> 1:1
> >> match, so I might have some investigation to do there.
> >> * MySQL Connector for Java v 5.1.7.
> >> * MySQL database running locally, Version: 5.0.67-0ubuntu6
> >> * Tests executed in Eclipse, YMMV outside of Eclipse.
> >> * Sun JDK 5 java full version "1.5.0_15-b04"
> >>
> >> I have done a lot of hacking about with the sample application but I
> >> don't
> >> think I've violated the intent of the exercise. I'll upload the app to a
> >> jira shortly.
> >>
> >> The relevant code is in my pastebin at these links :
> >> persistence.xml : http://miked.pastebin.com/m490814b7
> >> test01.java : http://miked.pastebin.com/m7d3df62f
> >> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
> >>
> >> I highlighted the changed lines in WarehouseDAO, but missed it on the
> >> others (too many lines to highlight accurately.
> >>
> >> I'm still looking, but thought this was worth sharing in case someone
> >> else
> >> sees something I've missed.
> >>
> >> -mike
> >>
> >>
> >>
> >> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland
> >> <te...@jotobjects.com>wrote:
> >>
> >>>
> >>> At one point in this thread it was mentioned that the benchmark ran
> much
> >>> faster on a home computer than on an office computer and the reason for
> >>> the
> >>> difference was not obvious. Was that difference explained yet?
> >>>
> >>> What version of OpenJPA is the test using?
> >>>
> >>> - Paul
> >>>
> >>>
> >>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
> >>>
> >>>> Shubbis and Nitish,
> >>>> Thanks for your efforts. So, to clarify -- all implementations are
> >>>> using
> >>>> similar configurations (ie. connection pooling, caching, enhancement,
> >>>> etc)?
> >>>> But, the OpenJPA performance is still 3 times slower than the
> >>>> competitors?
> >>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
> >>>> would
> >>>> expect some overhead as compared to iBatis and/or straight JDBC, but
> >>>> OpenJPA
> >>>> should be competitive (and beat) the Hibernates and EclipseLinks...
> >>>> Very
> >>>> frustrating. When we do our comparisons with the industry benchmarks
> >>>> (Trade
> >>>> and SpecJApp), OpenJPA is extremely competitive.
> >>>>
> >>>> I have not closely examined your benchmark project, so I don't know
> how
> >>>> it
> >>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
> >>>> topic?
> >>>>
> >>>> One other thought... Just to prove that the enhancement processing is
> >>>> being
> >>>> done and you're not falling into the sub-classing support, could you
> >>>> run
> >>>> with the following property? This will cause your application to
> >>>> error-off
> >>>> if your Entities are not byte-code enhanced. We will not fall into
> the
> >>>> sub-classing support which greatly affects the performance.
> >>>>
> >>>> <property name="openjpa.RuntimeUnenhancedClasses"
> >>>> value="warn"/>
> >>>>
> >>>> It really seems that you are trying to do a fair comparison, and I
> >>>> greatly
> >>>> appreciate your efforts. The last time one of these comparisons was
> >>>> posted,
> >>>> the benchmark code and process was flawed. So, I am pleased to see
> the
> >>>> efforts associated with this exercise.
> >>>>
> >>>> Our performance lead is out having a baby, so we haven't been able to
> >>>> dig
> >>>> into your benchmark to the extent that we would like. If we can
> verify
> >>>> that
> >>>> the enhancement processing is happening, that would be good input.
> >>>> Thanks
> >>>> for your patience. What kind of timeframe are you under for posting
> >>>> this
> >>>> benchmark?
> >>>>
> >>>> Thanks,
> >>>> Kevin
> >>>>
> >>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
> >>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Since we decided to go with vanilla installations of alle the
> >>>>> frameworks
> >>>>> we
> >>>>> have not added the connection pool feature to OpenJPA, until now.
> >>>>>
> >>>>> The results are sadly not that great. Yes, it's faster and it doesn't
> >>>>> run
> >>>>> out of connections like before, BUT it's still 3, yes, -three- times
> >>>>> slower
> >>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
> >>>>> entities with many relations.
> >>>>>
> >>>>> Clearly this is not the kind of results I was hoping for and I'm
> quite
> >>>>> perplexed as to what to do.
> >>>>>
> >>>>> Shubbis
> >>>>>
> >>>>>
> >>>>> Nitish Kumar wrote:
> >>>>>
> >>>>>
> >>>>>> Hi subbis,
> >>>>>> If I let the iteration loop over 5000, I get that exception, It
> >>>>>> seems (I am not sure) openjpa is creating a new connection and after
> >>>>>> a
> >>>>>> while mysql runs out of connection. I tried the same code and
> >>>>>> iteration
> >>>>>> loop with a connection pool and it works fine. That should get you
> >>>>>> moving as of now, till someone from Open JPA team looks into the
> >>>>>> issue.
> >>>>>>
> >>>>>> Thanks and Regards,
> >>>>>> Nitish Kumar
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> View this message in context:
> >>>>>
> >>>>>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
> >>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2516988.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2532837.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Michael Dick <mi...@gmail.com>.
Hi Shubbis,
Glad to help. Some comments inline.
On Sun, Mar 22, 2009 at 8:39 AM, Shubbis <ma...@broadpark.no> wrote:
>
> Hi Michael and everyone else involved!
>
> I greatly appreciate the efforts put into this and I'm glad to report that
> simple testing at home, with the same laptop I use during the project, it
> seems that i get the desired performance when enabling ConnectionRetainMode
> = always. I will of course continue testing when i get back to the office.
> Just to clarify, I'm not sure this is the end of all my worries ;)
>
> Note. I am running this without connection pooling as this was not a
> default
> setting of OpenJPA. The project specifies that all frameworks are run with
> minimal setting changes and "as vanilla as possible".
>
Is the separate download the deciding factor or is it the experimentation
required to get the pool configured "right"? Including commons-dbcp in our
binary distribution is easy to fix. If it would help in bake-offs like this
I think we'd have no trouble getting the required votes for a change.
> This does however not explain why i get much better results on my home
> laptop. Granted it is faster and has more memory, but I got the same
> results
> as Pinaki which would indicate (to me atleast) that the result on my home
> laptop is as it's "supposed" to be.
I'm not sure why you're getting different results. Your initial results
roughly matched mine so I went with them as a baseline. Maybe my laptop and
your work system are equally performance challenged :-).
Now, a question. Since this ConnectionRetainMode is not on always by
> default. Does this suggest that OpenJPA is supposed/(required?) to be run
> with a connection pool addon? I mean, if this was the case, why is it not
> included by default?
>
I wouldn't say a connection pool is required any more than a L2 cache is
required. It really depends on your use case. As you can tell when you run
with RetainMode and no pool, adding a pool doesn't always help and it can
lead to other interesting problems. Paul mentioned some in an earlier email.
In addition OpenJPA is often used with a JEE Application Server, which
typically provides its own connection pool. Having two levels of pooling can
lead to some interesting problems.
I suspect these are some of the reasons why OpenJPA was originally
distributed without an integrated connection pool (and you don't have to go
far to get commons-dbcp so why reinvent the wheel).
This specific test really benefits from having a single connection to the
database. There's only one thread using the DB, and it's just doing reads.
As long as the use case doesn't change you won't see much benefit from a
connection pool (you only need one connection anyway), or a L2 cache (the EM
has cached everything for you). Try setting the connection pool size to 1
for EclipseLink and OpenJPA and you might be surprised at the results.
When you start writing data and have multiple EMs involved then your options
become more intersting. Then you'll see benefits with a connection pool / L2
cache, etc.
I hope this made any sense, I'm having a hard time formulating coherent
> replies as this is my second language and I'm quite new to all of this
> (OpenJPA/JPA etc..).
>
You're doing better than I would do in my second language, I'm sure.
-mike
> Thanks again!
>
> Shubbis
>
>
>
> Michael Dick wrote:
> >
> > Hi all,
> >
> > As Paul pointed out privately I didn't indicate which versions of OpenJPA
> > I
> > was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT
> > primarily.
> > I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't
> > much
> > difference though so reduced the scope to 1.2 and trunk.
> >
> > The testcase uses a single EntityManager instance to issue a batch of
> > findBy
> > operations. In OpenJPA each findBy (or any query for that matter) obtains
> > a
> > connection from the connection pool and returns it after getting the
> > results. So we're spending a lot of time moving the connection to and
> from
> > the pool (some cleanup is done along the way).
> >
> > Fortunately this behavior can be configured with the
> > openjpa.ConnectionRetainMode property. Setting it to "always" causes the
> > EntityManager to hold on to a single connection until the EntityManager
> > closes. Obviously this setting introduces the possibility of exhausting
> > the
> > connection pool if num_entitymanagers > max_connections, but for this
> > benchmark it's safe to try.
> >
> > Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop
> at
> > 100 - 100,000 iterations. In addition I removed the
> > openjpa.jdbc.SynchronizeMappings property from the example (it's
> > extraneous
> > once the tables are created anyway).Another option I enabled that made
> > some
> > difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
> > has some pstmt caching as well, but that could be faulty - in which case
> > I'll disable it in dbcp.
> >
> > Here's the entire set of properties I'm using :
> > properties.put("openjpa.Log", "DefaultLevel=FATAL");
> > properties.put("openjpa.RuntimeUnenhancedClasses",
> "unsupported");
> > properties.put("openjpa.ConnectionRetainMode", "always");
> > properties.put("openjpa.ConnectionDriverName",
> > "org.apache.commons.dbcp.BasicDataSource");
> >
> > properties.put("openjpa.ConnectionProperties", String.format(
> > "DriverClassName=%s, Url=%s, username=%s, password=%s,"
> > + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
> > + ", poolPreparedStatements=true"
> > , JDBC_DRIVER, JDBC_URL, JDBC_USER,
> > JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
> >
> > EntityManagerFactory factory =
> > Persistence.createEntityManagerFactory("OpenJPAPU",
> > properties);
> >
> > MIN_CON = 1, MAX_CON=10.
> >
> > Shubbis, could you try running something similar and see if you get the
> > same
> > results?
> >
> > -mike
> >
> > On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick
> > <mi...@gmail.com>wrote:
> >
> >> Hi, I took a quick run with the source code from the RAR Shubbis
> attached
> >> earlier (thanks BTW).
> >>
> >> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
> >> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt
> >> EclipseLink
> >> is doing better (certainly not 3x) based solely on the SQL.
> >>
> >> So I started digging deeper and on my laptop (not to be confused with
> any
> >> sort of "real" benchmark) there's a sweet spot around 100 iterations.
> >> Under
> >> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over
> >> 125
> >> iterations EclipseLink starts pulling ahead.
> >>
> >> Environment :
> >> * Entities were enhanced by the PCEnhancer tool prior to running the
> >> tests.
> >>
> >> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
> >> the same settings. EclipseLink's pool and commons-dbcp weren't an easy
> >> 1:1
> >> match, so I might have some investigation to do there.
> >> * MySQL Connector for Java v 5.1.7.
> >> * MySQL database running locally, Version: 5.0.67-0ubuntu6
> >> * Tests executed in Eclipse, YMMV outside of Eclipse.
> >> * Sun JDK 5 java full version "1.5.0_15-b04"
> >>
> >> I have done a lot of hacking about with the sample application but I
> >> don't
> >> think I've violated the intent of the exercise. I'll upload the app to a
> >> jira shortly.
> >>
> >> The relevant code is in my pastebin at these links :
> >> persistence.xml : http://miked.pastebin.com/m490814b7
> >> test01.java : http://miked.pastebin.com/m7d3df62f
> >> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
> >>
> >> I highlighted the changed lines in WarehouseDAO, but missed it on the
> >> others (too many lines to highlight accurately.
> >>
> >> I'm still looking, but thought this was worth sharing in case someone
> >> else
> >> sees something I've missed.
> >>
> >> -mike
> >>
> >>
> >>
> >> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland
> >> <te...@jotobjects.com>wrote:
> >>
> >>>
> >>> At one point in this thread it was mentioned that the benchmark ran
> much
> >>> faster on a home computer than on an office computer and the reason for
> >>> the
> >>> difference was not obvious. Was that difference explained yet?
> >>>
> >>> What version of OpenJPA is the test using?
> >>>
> >>> - Paul
> >>>
> >>>
> >>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
> >>>
> >>>> Shubbis and Nitish,
> >>>> Thanks for your efforts. So, to clarify -- all implementations are
> >>>> using
> >>>> similar configurations (ie. connection pooling, caching, enhancement,
> >>>> etc)?
> >>>> But, the OpenJPA performance is still 3 times slower than the
> >>>> competitors?
> >>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
> >>>> would
> >>>> expect some overhead as compared to iBatis and/or straight JDBC, but
> >>>> OpenJPA
> >>>> should be competitive (and beat) the Hibernates and EclipseLinks...
> >>>> Very
> >>>> frustrating. When we do our comparisons with the industry benchmarks
> >>>> (Trade
> >>>> and SpecJApp), OpenJPA is extremely competitive.
> >>>>
> >>>> I have not closely examined your benchmark project, so I don't know
> how
> >>>> it
> >>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
> >>>> topic?
> >>>>
> >>>> One other thought... Just to prove that the enhancement processing is
> >>>> being
> >>>> done and you're not falling into the sub-classing support, could you
> >>>> run
> >>>> with the following property? This will cause your application to
> >>>> error-off
> >>>> if your Entities are not byte-code enhanced. We will not fall into
> the
> >>>> sub-classing support which greatly affects the performance.
> >>>>
> >>>> <property name="openjpa.RuntimeUnenhancedClasses"
> >>>> value="warn"/>
> >>>>
> >>>> It really seems that you are trying to do a fair comparison, and I
> >>>> greatly
> >>>> appreciate your efforts. The last time one of these comparisons was
> >>>> posted,
> >>>> the benchmark code and process was flawed. So, I am pleased to see
> the
> >>>> efforts associated with this exercise.
> >>>>
> >>>> Our performance lead is out having a baby, so we haven't been able to
> >>>> dig
> >>>> into your benchmark to the extent that we would like. If we can
> verify
> >>>> that
> >>>> the enhancement processing is happening, that would be good input.
> >>>> Thanks
> >>>> for your patience. What kind of timeframe are you under for posting
> >>>> this
> >>>> benchmark?
> >>>>
> >>>> Thanks,
> >>>> Kevin
> >>>>
> >>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
> >>>> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Since we decided to go with vanilla installations of alle the
> >>>>> frameworks
> >>>>> we
> >>>>> have not added the connection pool feature to OpenJPA, until now.
> >>>>>
> >>>>> The results are sadly not that great. Yes, it's faster and it doesn't
> >>>>> run
> >>>>> out of connections like before, BUT it's still 3, yes, -three- times
> >>>>> slower
> >>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
> >>>>> entities with many relations.
> >>>>>
> >>>>> Clearly this is not the kind of results I was hoping for and I'm
> quite
> >>>>> perplexed as to what to do.
> >>>>>
> >>>>> Shubbis
> >>>>>
> >>>>>
> >>>>> Nitish Kumar wrote:
> >>>>>
> >>>>>
> >>>>>> Hi subbis,
> >>>>>> If I let the iteration loop over 5000, I get that exception, It
> >>>>>> seems (I am not sure) openjpa is creating a new connection and after
> >>>>>> a
> >>>>>> while mysql runs out of connection. I tried the same code and
> >>>>>> iteration
> >>>>>> loop with a connection pool and it works fine. That should get you
> >>>>>> moving as of now, till someone from Open JPA team looks into the
> >>>>>> issue.
> >>>>>>
> >>>>>> Thanks and Regards,
> >>>>>> Nitish Kumar
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> View this message in context:
> >>>>>
> >>>>>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
> >>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2516988.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Hi Michael and everyone else involved!
I greatly appreciate the efforts put into this and I'm glad to report that
simple testing at home, with the same laptop I use during the project, it
seems that i get the desired performance when enabling ConnectionRetainMode
= always. I will of course continue testing when i get back to the office.
Just to clarify, I'm not sure this is the end of all my worries ;)
Note. I am running this without connection pooling as this was not a default
setting of OpenJPA. The project specifies that all frameworks are run with
minimal setting changes and "as vanilla as possible".
This does however not explain why i get much better results on my home
laptop. Granted it is faster and has more memory, but I got the same results
as Pinaki which would indicate (to me atleast) that the result on my home
laptop is as it's "supposed" to be.
Now, a question. Since this ConnectionRetainMode is not on always by
default. Does this suggest that OpenJPA is supposed/(required?) to be run
with a connection pool addon? I mean, if this was the case, why is it not
included by default?
I hope this made any sense, I'm having a hard time formulating coherent
replies as this is my second language and I'm quite new to all of this
(OpenJPA/JPA etc..).
Thanks again!
Shubbis
Michael Dick wrote:
>
> Hi all,
>
> As Paul pointed out privately I didn't indicate which versions of OpenJPA
> I
> was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT
> primarily.
> I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't
> much
> difference though so reduced the scope to 1.2 and trunk.
>
> The testcase uses a single EntityManager instance to issue a batch of
> findBy
> operations. In OpenJPA each findBy (or any query for that matter) obtains
> a
> connection from the connection pool and returns it after getting the
> results. So we're spending a lot of time moving the connection to and from
> the pool (some cleanup is done along the way).
>
> Fortunately this behavior can be configured with the
> openjpa.ConnectionRetainMode property. Setting it to "always" causes the
> EntityManager to hold on to a single connection until the EntityManager
> closes. Obviously this setting introduces the possibility of exhausting
> the
> connection pool if num_entitymanagers > max_connections, but for this
> benchmark it's safe to try.
>
> Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop at
> 100 - 100,000 iterations. In addition I removed the
> openjpa.jdbc.SynchronizeMappings property from the example (it's
> extraneous
> once the tables are created anyway).Another option I enabled that made
> some
> difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
> has some pstmt caching as well, but that could be faulty - in which case
> I'll disable it in dbcp.
>
> Here's the entire set of properties I'm using :
> properties.put("openjpa.Log", "DefaultLevel=FATAL");
> properties.put("openjpa.RuntimeUnenhancedClasses", "unsupported");
> properties.put("openjpa.ConnectionRetainMode", "always");
> properties.put("openjpa.ConnectionDriverName",
> "org.apache.commons.dbcp.BasicDataSource");
>
> properties.put("openjpa.ConnectionProperties", String.format(
> "DriverClassName=%s, Url=%s, username=%s, password=%s,"
> + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
> + ", poolPreparedStatements=true"
> , JDBC_DRIVER, JDBC_URL, JDBC_USER,
> JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
>
> EntityManagerFactory factory =
> Persistence.createEntityManagerFactory("OpenJPAPU",
> properties);
>
> MIN_CON = 1, MAX_CON=10.
>
> Shubbis, could you try running something similar and see if you get the
> same
> results?
>
> -mike
>
> On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick
> <mi...@gmail.com>wrote:
>
>> Hi, I took a quick run with the source code from the RAR Shubbis attached
>> earlier (thanks BTW).
>>
>> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
>> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt
>> EclipseLink
>> is doing better (certainly not 3x) based solely on the SQL.
>>
>> So I started digging deeper and on my laptop (not to be confused with any
>> sort of "real" benchmark) there's a sweet spot around 100 iterations.
>> Under
>> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over
>> 125
>> iterations EclipseLink starts pulling ahead.
>>
>> Environment :
>> * Entities were enhanced by the PCEnhancer tool prior to running the
>> tests.
>>
>> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
>> the same settings. EclipseLink's pool and commons-dbcp weren't an easy
>> 1:1
>> match, so I might have some investigation to do there.
>> * MySQL Connector for Java v 5.1.7.
>> * MySQL database running locally, Version: 5.0.67-0ubuntu6
>> * Tests executed in Eclipse, YMMV outside of Eclipse.
>> * Sun JDK 5 java full version "1.5.0_15-b04"
>>
>> I have done a lot of hacking about with the sample application but I
>> don't
>> think I've violated the intent of the exercise. I'll upload the app to a
>> jira shortly.
>>
>> The relevant code is in my pastebin at these links :
>> persistence.xml : http://miked.pastebin.com/m490814b7
>> test01.java : http://miked.pastebin.com/m7d3df62f
>> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
>>
>> I highlighted the changed lines in WarehouseDAO, but missed it on the
>> others (too many lines to highlight accurately.
>>
>> I'm still looking, but thought this was worth sharing in case someone
>> else
>> sees something I've missed.
>>
>> -mike
>>
>>
>>
>> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland
>> <te...@jotobjects.com>wrote:
>>
>>>
>>> At one point in this thread it was mentioned that the benchmark ran much
>>> faster on a home computer than on an office computer and the reason for
>>> the
>>> difference was not obvious. Was that difference explained yet?
>>>
>>> What version of OpenJPA is the test using?
>>>
>>> - Paul
>>>
>>>
>>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
>>>
>>>> Shubbis and Nitish,
>>>> Thanks for your efforts. So, to clarify -- all implementations are
>>>> using
>>>> similar configurations (ie. connection pooling, caching, enhancement,
>>>> etc)?
>>>> But, the OpenJPA performance is still 3 times slower than the
>>>> competitors?
>>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
>>>> would
>>>> expect some overhead as compared to iBatis and/or straight JDBC, but
>>>> OpenJPA
>>>> should be competitive (and beat) the Hibernates and EclipseLinks...
>>>> Very
>>>> frustrating. When we do our comparisons with the industry benchmarks
>>>> (Trade
>>>> and SpecJApp), OpenJPA is extremely competitive.
>>>>
>>>> I have not closely examined your benchmark project, so I don't know how
>>>> it
>>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
>>>> topic?
>>>>
>>>> One other thought... Just to prove that the enhancement processing is
>>>> being
>>>> done and you're not falling into the sub-classing support, could you
>>>> run
>>>> with the following property? This will cause your application to
>>>> error-off
>>>> if your Entities are not byte-code enhanced. We will not fall into the
>>>> sub-classing support which greatly affects the performance.
>>>>
>>>> <property name="openjpa.RuntimeUnenhancedClasses"
>>>> value="warn"/>
>>>>
>>>> It really seems that you are trying to do a fair comparison, and I
>>>> greatly
>>>> appreciate your efforts. The last time one of these comparisons was
>>>> posted,
>>>> the benchmark code and process was flawed. So, I am pleased to see the
>>>> efforts associated with this exercise.
>>>>
>>>> Our performance lead is out having a baby, so we haven't been able to
>>>> dig
>>>> into your benchmark to the extent that we would like. If we can verify
>>>> that
>>>> the enhancement processing is happening, that would be good input.
>>>> Thanks
>>>> for your patience. What kind of timeframe are you under for posting
>>>> this
>>>> benchmark?
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Since we decided to go with vanilla installations of alle the
>>>>> frameworks
>>>>> we
>>>>> have not added the connection pool feature to OpenJPA, until now.
>>>>>
>>>>> The results are sadly not that great. Yes, it's faster and it doesn't
>>>>> run
>>>>> out of connections like before, BUT it's still 3, yes, -three- times
>>>>> slower
>>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>>>>> entities with many relations.
>>>>>
>>>>> Clearly this is not the kind of results I was hoping for and I'm quite
>>>>> perplexed as to what to do.
>>>>>
>>>>> Shubbis
>>>>>
>>>>>
>>>>> Nitish Kumar wrote:
>>>>>
>>>>>
>>>>>> Hi subbis,
>>>>>> If I let the iteration loop over 5000, I get that exception, It
>>>>>> seems (I am not sure) openjpa is creating a new connection and after
>>>>>> a
>>>>>> while mysql runs out of connection. I tried the same code and
>>>>>> iteration
>>>>>> loop with a connection pool and it works fine. That should get you
>>>>>> moving as of now, till someone from Open JPA team looks into the
>>>>>> issue.
>>>>>>
>>>>>> Thanks and Regards,
>>>>>> Nitish Kumar
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2516988.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Paul Copeland <te...@jotobjects.com>.
Two cents - It would be useful to examine the use cases that benefit
from a JPA implementation having its own integrated connection pool.
Most J2EE containers already have abstractions for connection pool
resources. Also, long running connections have other issues with
concurrency and locking beyond worrying about connection pool
starvation. The tradeoffs on a case by case basis can only be
understood at the application level. For instance, a long running batch
program that runs occasionally may not even use the same pool that
interactive processes use.
- Paul
On 3/21/2009 8:18 AM, Michael Dick wrote:
> Hi Nitish,
>
> I'm not sure there is a best answer. In this case it's a bit of a tradeoff.
> If you're not actively driving work on a connection why would one want to
> hold on to a connection? Say you have long lived EntityManagers which use
> resource local transactions. If we maintain the connection until the
> EntityManager is closed then the connection pool size is 1:1 with the number
> of EMs (which might be 1 per thread). Right now we're taking the stance that
> the connection pool is better able to load balance if we return the
> connection to the pool immediately.
>
> With JTA the scenario changes a bit. In my experience with JTA aware
> connection pools the connection doesn't really go back to the pool when we
> (the app) close it. Rather it's reserved for future use in the same JTA tran
> (this might be implementation specific though). In which case the cleanup
> which causes a lot of the overhead wouldn't even happen until the JTA tran
> completes.
>
> I'm less familiar with Spring transactions (suppose I have some reading to
> do).
>
> I'm not ready to say either approach is right or wrong. It really depends on
> your use case. By default we try to keep the number of connections low and
> avoid contention for database resources which makes sense for bigger
> applications. Smaller ones might prefer setting retainMode=transaction or
> always.
>
> What this is pointing out to me is that there's some benefit in having an
> integrated connection pool in a JPA provider. I believe someone posted about
> the idea a few weeks ago but I don't remember what came of it - based on
> this thread I think it's worth revisiting.
>
> -mike
>
>
>
>
>> Hi Michael,
>> The connection retain mode property makes the numbers almost same,
>> but I am a little confused. Shouldnt this be the default behavior of Entity
>> Manager? Typically I would have the entity manager tied up to the
>> transaction (JTA or Spring), so I would expect Entity Manager to hold the
>> connection always.
>>
>> Thanks and Regards,
>> Nitish Kumar
>>
>> -----Original Message-----
>> From: Michael Dick [mailto:michael.d.dick@gmail.com]
>> Sent: Sat 3/21/2009 1:55 AM
>> To: users@openjpa.apache.org
>> Subject: Re: Slow performance with OpenJPA when selecting from a ManyToMany
>> relation.
>>
>> Hi all,
>>
>> As Paul pointed out privately I didn't indicate which versions of OpenJPA I
>> was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT
>> primarily.
>> I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't
>> much
>> difference though so reduced the scope to 1.2 and trunk.
>>
>> The testcase uses a single EntityManager instance to issue a batch of
>> findBy
>> operations. In OpenJPA each findBy (or any query for that matter) obtains a
>> connection from the connection pool and returns it after getting the
>> results. So we're spending a lot of time moving the connection to and from
>> the pool (some cleanup is done along the way).
>>
>> Fortunately this behavior can be configured with the
>> openjpa.ConnectionRetainMode property. Setting it to "always" causes the
>> EntityManager to hold on to a single connection until the EntityManager
>> closes. Obviously this setting introduces the possibility of exhausting the
>> connection pool if num_entitymanagers > max_connections, but for this
>> benchmark it's safe to try.
>>
>> Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop at
>> 100 - 100,000 iterations. In addition I removed the
>> openjpa.jdbc.SynchronizeMappings property from the example (it's extraneous
>> once the tables are created anyway).Another option I enabled that made some
>> difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
>> has some pstmt caching as well, but that could be faulty - in which case
>> I'll disable it in dbcp.
>>
>> Here's the entire set of properties I'm using :
>> properties.put("openjpa.Log", "DefaultLevel=FATAL");
>> properties.put("openjpa.RuntimeUnenhancedClasses", "unsupported");
>> properties.put("openjpa.ConnectionRetainMode", "always");
>> properties.put("openjpa.ConnectionDriverName",
>> "org.apache.commons.dbcp.BasicDataSource");
>>
>> properties.put("openjpa.ConnectionProperties", String.format(
>> "DriverClassName=%s, Url=%s, username=%s, password=%s,"
>> + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
>> + ", poolPreparedStatements=true"
>> , JDBC_DRIVER, JDBC_URL, JDBC_USER,
>> JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
>>
>> EntityManagerFactory factory =
>> Persistence.createEntityManagerFactory("OpenJPAPU", properties);
>>
>> MIN_CON = 1, MAX_CON=10.
>>
>> Shubbis, could you try running something similar and see if you get the
>> same
>> results?
>>
>> -mike
>>
>> On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick <michael.d.dick@gmail.com
>>
>>> wrote:
>>>
>>> Hi, I took a quick run with the source code from the RAR Shubbis attached
>>> earlier (thanks BTW).
>>>
>>> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
>>> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt
>>>
>> EclipseLink
>>
>>> is doing better (certainly not 3x) based solely on the SQL.
>>>
>>> So I started digging deeper and on my laptop (not to be confused with any
>>> sort of "real" benchmark) there's a sweet spot around 100 iterations.
>>>
>> Under
>>
>>> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over
>>>
>> 125
>>
>>> iterations EclipseLink starts pulling ahead.
>>>
>>> Environment :
>>> * Entities were enhanced by the PCEnhancer tool prior to running the
>>>
>> tests.
>>
>>> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
>>> the same settings. EclipseLink's pool and commons-dbcp weren't an easy
>>>
>> 1:1
>>
>>> match, so I might have some investigation to do there.
>>> * MySQL Connector for Java v 5.1.7.
>>> * MySQL database running locally, Version: 5.0.67-0ubuntu6
>>> * Tests executed in Eclipse, YMMV outside of Eclipse.
>>> * Sun JDK 5 java full version "1.5.0_15-b04"
>>>
>>> I have done a lot of hacking about with the sample application but I
>>>
>> don't
>>
>>> think I've violated the intent of the exercise. I'll upload the app to a
>>> jira shortly.
>>>
>>> The relevant code is in my pastebin at these links :
>>> persistence.xml : http://miked.pastebin.com/m490814b7
>>> test01.java : http://miked.pastebin.com/m7d3df62f
>>> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
>>>
>>> I highlighted the changed lines in WarehouseDAO, but missed it on the
>>> others (too many lines to highlight accurately.
>>>
>>> I'm still looking, but thought this was worth sharing in case someone
>>>
>> else
>>
>>> sees something I've missed.
>>>
>>> -mike
>>>
>>>
>>>
>>> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland <tech@jotobjects.com
>>> wrote:
>>>
>>>
>>>> At one point in this thread it was mentioned that the benchmark ran much
>>>> faster on a home computer than on an office computer and the reason for
>>>>
>> the
>>
>>>> difference was not obvious. Was that difference explained yet?
>>>>
>>>> What version of OpenJPA is the test using?
>>>>
>>>> - Paul
>>>>
>>>>
>>>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
>>>>
>>>>
>>>>> Shubbis and Nitish,
>>>>> Thanks for your efforts. So, to clarify -- all implementations are
>>>>>
>> using
>>
>>>>> similar configurations (ie. connection pooling, caching, enhancement,
>>>>> etc)?
>>>>> But, the OpenJPA performance is still 3 times slower than the
>>>>> competitors?
>>>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
>>>>> would
>>>>> expect some overhead as compared to iBatis and/or straight JDBC, but
>>>>> OpenJPA
>>>>> should be competitive (and beat) the Hibernates and EclipseLinks...
>>>>>
>> Very
>>
>>>>> frustrating. When we do our comparisons with the industry benchmarks
>>>>> (Trade
>>>>> and SpecJApp), OpenJPA is extremely competitive.
>>>>>
>>>>> I have not closely examined your benchmark project, so I don't know how
>>>>> it
>>>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
>>>>> topic?
>>>>>
>>>>> One other thought... Just to prove that the enhancement processing is
>>>>> being
>>>>> done and you're not falling into the sub-classing support, could you
>>>>>
>> run
>>
>>>>> with the following property? This will cause your application to
>>>>> error-off
>>>>> if your Entities are not byte-code enhanced. We will not fall into the
>>>>> sub-classing support which greatly affects the performance.
>>>>>
>>>>> <property name="openjpa.RuntimeUnenhancedClasses"
>>>>> value="warn"/>
>>>>>
>>>>> It really seems that you are trying to do a fair comparison, and I
>>>>> greatly
>>>>> appreciate your efforts. The last time one of these comparisons was
>>>>> posted,
>>>>> the benchmark code and process was flawed. So, I am pleased to see the
>>>>> efforts associated with this exercise.
>>>>>
>>>>> Our performance lead is out having a baby, so we haven't been able to
>>>>>
>> dig
>>
>>>>> into your benchmark to the extent that we would like. If we can verify
>>>>> that
>>>>> the enhancement processing is happening, that would be good input.
>>>>> Thanks
>>>>> for your patience. What kind of timeframe are you under for posting
>>>>>
>> this
>>
>>>>> benchmark?
>>>>>
>>>>> Thanks,
>>>>> Kevin
>>>>>
>>>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Since we decided to go with vanilla installations of alle the
>>>>>>
>> frameworks
>>
>>>>>> we
>>>>>> have not added the connection pool feature to OpenJPA, until now.
>>>>>>
>>>>>> The results are sadly not that great. Yes, it's faster and it doesn't
>>>>>> run
>>>>>> out of connections like before, BUT it's still 3, yes, -three- times
>>>>>> slower
>>>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>>>>>> entities with many relations.
>>>>>>
>>>>>> Clearly this is not the kind of results I was hoping for and I'm quite
>>>>>> perplexed as to what to do.
>>>>>>
>>>>>> Shubbis
>>>>>>
>>>>>>
>>>>>> Nitish Kumar wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi subbis,
>>>>>>> If I let the iteration loop over 5000, I get that exception, It
>>>>>>> seems (I am not sure) openjpa is creating a new connection and after
>>>>>>>
>> a
>>
>>>>>>> while mysql runs out of connection. I tried the same code and
>>>>>>>
>> iteration
>>
>>>>>>> loop with a connection pool and it works fine. That should get you
>>>>>>> moving as of now, till someone from Open JPA team looks into the
>>>>>>>
>> issue.
>>
>>>>>>> Thanks and Regards,
>>>>>>> Nitish Kumar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>>
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>>
>>>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> -------------------------------------------------------------------------------------------------------------------------
>> "The information contained in this e-mail transmission is confidential and
>> may be privileged. It is intended only for the
>> addressee(s) stated above. If you are not an addressee, any use,
>> dissemination, distribution, publication, or copying of
>> the information contained in this e-mail is strictly prohibited. If you
>> have received this e-mail in error, please
>> immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender
>> and delete the e-mail from your system.
>> If you do not want to receive our emails please let us know so that we may
>> delete you from our email list. Proteans
>> Software Solutions and its parent group ("CAMO Group") do not accept
>> liability for damage caused by this email, and may
>> monitor email traffic."
>>
>> -------------------------------------------------------------------------------------------------------------------------
>>
>>
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Michael Dick <mi...@gmail.com>.
Hi Nitish,
I'm not sure there is a best answer. In this case it's a bit of a tradeoff.
If you're not actively driving work on a connection why would one want to
hold on to a connection? Say you have long lived EntityManagers which use
resource local transactions. If we maintain the connection until the
EntityManager is closed then the connection pool size is 1:1 with the number
of EMs (which might be 1 per thread). Right now we're taking the stance that
the connection pool is better able to load balance if we return the
connection to the pool immediately.
With JTA the scenario changes a bit. In my experience with JTA aware
connection pools the connection doesn't really go back to the pool when we
(the app) close it. Rather it's reserved for future use in the same JTA tran
(this might be implementation specific though). In which case the cleanup
which causes a lot of the overhead wouldn't even happen until the JTA tran
completes.
I'm less familiar with Spring transactions (suppose I have some reading to
do).
I'm not ready to say either approach is right or wrong. It really depends on
your use case. By default we try to keep the number of connections low and
avoid contention for database resources which makes sense for bigger
applications. Smaller ones might prefer setting retainMode=transaction or
always.
What this is pointing out to me is that there's some benefit in having an
integrated connection pool in a JPA provider. I believe someone posted about
the idea a few weeks ago but I don't remember what came of it - based on
this thread I think it's worth revisiting.
-mike
> Hi Michael,
> The connection retain mode property makes the numbers almost same,
> but I am a little confused. Shouldnt this be the default behavior of Entity
> Manager? Typically I would have the entity manager tied up to the
> transaction (JTA or Spring), so I would expect Entity Manager to hold the
> connection always.
>
> Thanks and Regards,
> Nitish Kumar
>
> -----Original Message-----
> From: Michael Dick [mailto:michael.d.dick@gmail.com]
> Sent: Sat 3/21/2009 1:55 AM
> To: users@openjpa.apache.org
> Subject: Re: Slow performance with OpenJPA when selecting from a ManyToMany
> relation.
>
> Hi all,
>
> As Paul pointed out privately I didn't indicate which versions of OpenJPA I
> was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT
> primarily.
> I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't
> much
> difference though so reduced the scope to 1.2 and trunk.
>
> The testcase uses a single EntityManager instance to issue a batch of
> findBy
> operations. In OpenJPA each findBy (or any query for that matter) obtains a
> connection from the connection pool and returns it after getting the
> results. So we're spending a lot of time moving the connection to and from
> the pool (some cleanup is done along the way).
>
> Fortunately this behavior can be configured with the
> openjpa.ConnectionRetainMode property. Setting it to "always" causes the
> EntityManager to hold on to a single connection until the EntityManager
> closes. Obviously this setting introduces the possibility of exhausting the
> connection pool if num_entitymanagers > max_connections, but for this
> benchmark it's safe to try.
>
> Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop at
> 100 - 100,000 iterations. In addition I removed the
> openjpa.jdbc.SynchronizeMappings property from the example (it's extraneous
> once the tables are created anyway).Another option I enabled that made some
> difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
> has some pstmt caching as well, but that could be faulty - in which case
> I'll disable it in dbcp.
>
> Here's the entire set of properties I'm using :
> properties.put("openjpa.Log", "DefaultLevel=FATAL");
> properties.put("openjpa.RuntimeUnenhancedClasses", "unsupported");
> properties.put("openjpa.ConnectionRetainMode", "always");
> properties.put("openjpa.ConnectionDriverName",
> "org.apache.commons.dbcp.BasicDataSource");
>
> properties.put("openjpa.ConnectionProperties", String.format(
> "DriverClassName=%s, Url=%s, username=%s, password=%s,"
> + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
> + ", poolPreparedStatements=true"
> , JDBC_DRIVER, JDBC_URL, JDBC_USER,
> JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
>
> EntityManagerFactory factory =
> Persistence.createEntityManagerFactory("OpenJPAPU", properties);
>
> MIN_CON = 1, MAX_CON=10.
>
> Shubbis, could you try running something similar and see if you get the
> same
> results?
>
> -mike
>
> On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick <michael.d.dick@gmail.com
> >wrote:
>
> > Hi, I took a quick run with the source code from the RAR Shubbis attached
> > earlier (thanks BTW).
> >
> > The SQL we execute for this findBy is SELECT t0.warehouseName FROM
> > Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt
> EclipseLink
> > is doing better (certainly not 3x) based solely on the SQL.
> >
> > So I started digging deeper and on my laptop (not to be confused with any
> > sort of "real" benchmark) there's a sweet spot around 100 iterations.
> Under
> > 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over
> 125
> > iterations EclipseLink starts pulling ahead.
> >
> > Environment :
> > * Entities were enhanced by the PCEnhancer tool prior to running the
> tests.
> >
> > * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
> > the same settings. EclipseLink's pool and commons-dbcp weren't an easy
> 1:1
> > match, so I might have some investigation to do there.
> > * MySQL Connector for Java v 5.1.7.
> > * MySQL database running locally, Version: 5.0.67-0ubuntu6
> > * Tests executed in Eclipse, YMMV outside of Eclipse.
> > * Sun JDK 5 java full version "1.5.0_15-b04"
> >
> > I have done a lot of hacking about with the sample application but I
> don't
> > think I've violated the intent of the exercise. I'll upload the app to a
> > jira shortly.
> >
> > The relevant code is in my pastebin at these links :
> > persistence.xml : http://miked.pastebin.com/m490814b7
> > test01.java : http://miked.pastebin.com/m7d3df62f
> > WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
> >
> > I highlighted the changed lines in WarehouseDAO, but missed it on the
> > others (too many lines to highlight accurately.
> >
> > I'm still looking, but thought this was worth sharing in case someone
> else
> > sees something I've missed.
> >
> > -mike
> >
> >
> >
> > On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland <tech@jotobjects.com
> >wrote:
> >
> >>
> >> At one point in this thread it was mentioned that the benchmark ran much
> >> faster on a home computer than on an office computer and the reason for
> the
> >> difference was not obvious. Was that difference explained yet?
> >>
> >> What version of OpenJPA is the test using?
> >>
> >> - Paul
> >>
> >>
> >> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
> >>
> >>> Shubbis and Nitish,
> >>> Thanks for your efforts. So, to clarify -- all implementations are
> using
> >>> similar configurations (ie. connection pooling, caching, enhancement,
> >>> etc)?
> >>> But, the OpenJPA performance is still 3 times slower than the
> >>> competitors?
> >>> In all of the scenarios? Or, just with this ManyToMany scenario? I
> >>> would
> >>> expect some overhead as compared to iBatis and/or straight JDBC, but
> >>> OpenJPA
> >>> should be competitive (and beat) the Hibernates and EclipseLinks...
> Very
> >>> frustrating. When we do our comparisons with the industry benchmarks
> >>> (Trade
> >>> and SpecJApp), OpenJPA is extremely competitive.
> >>>
> >>> I have not closely examined your benchmark project, so I don't know how
> >>> it
> >>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
> >>> topic?
> >>>
> >>> One other thought... Just to prove that the enhancement processing is
> >>> being
> >>> done and you're not falling into the sub-classing support, could you
> run
> >>> with the following property? This will cause your application to
> >>> error-off
> >>> if your Entities are not byte-code enhanced. We will not fall into the
> >>> sub-classing support which greatly affects the performance.
> >>>
> >>> <property name="openjpa.RuntimeUnenhancedClasses"
> >>> value="warn"/>
> >>>
> >>> It really seems that you are trying to do a fair comparison, and I
> >>> greatly
> >>> appreciate your efforts. The last time one of these comparisons was
> >>> posted,
> >>> the benchmark code and process was flawed. So, I am pleased to see the
> >>> efforts associated with this exercise.
> >>>
> >>> Our performance lead is out having a baby, so we haven't been able to
> dig
> >>> into your benchmark to the extent that we would like. If we can verify
> >>> that
> >>> the enhancement processing is happening, that would be good input.
> >>> Thanks
> >>> for your patience. What kind of timeframe are you under for posting
> this
> >>> benchmark?
> >>>
> >>> Thanks,
> >>> Kevin
> >>>
> >>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
> >>> wrote:
> >>>
> >>>
> >>>
> >>>> Since we decided to go with vanilla installations of alle the
> frameworks
> >>>> we
> >>>> have not added the connection pool feature to OpenJPA, until now.
> >>>>
> >>>> The results are sadly not that great. Yes, it's faster and it doesn't
> >>>> run
> >>>> out of connections like before, BUT it's still 3, yes, -three- times
> >>>> slower
> >>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
> >>>> entities with many relations.
> >>>>
> >>>> Clearly this is not the kind of results I was hoping for and I'm quite
> >>>> perplexed as to what to do.
> >>>>
> >>>> Shubbis
> >>>>
> >>>>
> >>>> Nitish Kumar wrote:
> >>>>
> >>>>
> >>>>> Hi subbis,
> >>>>> If I let the iteration loop over 5000, I get that exception, It
> >>>>> seems (I am not sure) openjpa is creating a new connection and after
> a
> >>>>> while mysql runs out of connection. I tried the same code and
> iteration
> >>>>> loop with a connection pool and it works fine. That should get you
> >>>>> moving as of now, till someone from Open JPA team looks into the
> issue.
> >>>>>
> >>>>> Thanks and Regards,
> >>>>> Nitish Kumar
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> View this message in context:
> >>>>
> >>>>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
> >>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
>
>
>
> -------------------------------------------------------------------------------------------------------------------------
> "The information contained in this e-mail transmission is confidential and
> may be privileged. It is intended only for the
> addressee(s) stated above. If you are not an addressee, any use,
> dissemination, distribution, publication, or copying of
> the information contained in this e-mail is strictly prohibited. If you
> have received this e-mail in error, please
> immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender
> and delete the e-mail from your system.
> If you do not want to receive our emails please let us know so that we may
> delete you from our email list. Proteans
> Software Solutions and its parent group ("CAMO Group") do not accept
> liability for damage caused by this email, and may
> monitor email traffic."
>
> -------------------------------------------------------------------------------------------------------------------------
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Paul Copeland <te...@jotobjects.com>.
Nitish -
I have the same question - I guess you cannot release the connection
while the transaction is open.
In my case I think the Entity Manager will exist for the duration of a
transaction in a Servlet Request.
- Paul
On 3/20/2009 10:57 PM, Nitish Kumar wrote:
> Hi Michael,
> The connection retain mode property makes the numbers almost same, but I am a little confused. Shouldnt this be the default behavior of Entity Manager? Typically I would have the entity manager tied up to the transaction (JTA or Spring), so I would expect Entity Manager to hold the connection always.
>
> Thanks and Regards,
> Nitish Kumar
>
> -----Original Message-----
> From: Michael Dick [mailto:michael.d.dick@gmail.com]
> Sent: Sat 3/21/2009 1:55 AM
> To: users@openjpa.apache.org
> Subject: Re: Slow performance with OpenJPA when selecting from a ManyToMany relation.
>
> Hi all,
>
> As Paul pointed out privately I didn't indicate which versions of OpenJPA I
> was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT primarily.
> I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't much
> difference though so reduced the scope to 1.2 and trunk.
>
> The testcase uses a single EntityManager instance to issue a batch of findBy
> operations. In OpenJPA each findBy (or any query for that matter) obtains a
> connection from the connection pool and returns it after getting the
> results. So we're spending a lot of time moving the connection to and from
> the pool (some cleanup is done along the way).
>
> Fortunately this behavior can be configured with the
> openjpa.ConnectionRetainMode property. Setting it to "always" causes the
> EntityManager to hold on to a single connection until the EntityManager
> closes. Obviously this setting introduces the possibility of exhausting the
> connection pool if num_entitymanagers > max_connections, but for this
> benchmark it's safe to try.
>
> Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop at
> 100 - 100,000 iterations. In addition I removed the
> openjpa.jdbc.SynchronizeMappings property from the example (it's extraneous
> once the tables are created anyway).Another option I enabled that made some
> difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
> has some pstmt caching as well, but that could be faulty - in which case
> I'll disable it in dbcp.
>
> Here's the entire set of properties I'm using :
> properties.put("openjpa.Log", "DefaultLevel=FATAL");
> properties.put("openjpa.RuntimeUnenhancedClasses", "unsupported");
> properties.put("openjpa.ConnectionRetainMode", "always");
> properties.put("openjpa.ConnectionDriverName",
> "org.apache.commons.dbcp.BasicDataSource");
>
> properties.put("openjpa.ConnectionProperties", String.format(
> "DriverClassName=%s, Url=%s, username=%s, password=%s,"
> + " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
> + ", poolPreparedStatements=true"
> , JDBC_DRIVER, JDBC_URL, JDBC_USER,
> JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
>
> EntityManagerFactory factory =
> Persistence.createEntityManagerFactory("OpenJPAPU", properties);
>
> MIN_CON = 1, MAX_CON=10.
>
> Shubbis, could you try running something similar and see if you get the same
> results?
>
> -mike
>
> On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick <mi...@gmail.com>wrote:
>
>
>> Hi, I took a quick run with the source code from the RAR Shubbis attached
>> earlier (thanks BTW).
>>
>> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
>> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt EclipseLink
>> is doing better (certainly not 3x) based solely on the SQL.
>>
>> So I started digging deeper and on my laptop (not to be confused with any
>> sort of "real" benchmark) there's a sweet spot around 100 iterations. Under
>> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over 125
>> iterations EclipseLink starts pulling ahead.
>>
>> Environment :
>> * Entities were enhanced by the PCEnhancer tool prior to running the tests.
>>
>> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
>> the same settings. EclipseLink's pool and commons-dbcp weren't an easy 1:1
>> match, so I might have some investigation to do there.
>> * MySQL Connector for Java v 5.1.7.
>> * MySQL database running locally, Version: 5.0.67-0ubuntu6
>> * Tests executed in Eclipse, YMMV outside of Eclipse.
>> * Sun JDK 5 java full version "1.5.0_15-b04"
>>
>> I have done a lot of hacking about with the sample application but I don't
>> think I've violated the intent of the exercise. I'll upload the app to a
>> jira shortly.
>>
>> The relevant code is in my pastebin at these links :
>> persistence.xml : http://miked.pastebin.com/m490814b7
>> test01.java : http://miked.pastebin.com/m7d3df62f
>> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
>>
>> I highlighted the changed lines in WarehouseDAO, but missed it on the
>> others (too many lines to highlight accurately.
>>
>> I'm still looking, but thought this was worth sharing in case someone else
>> sees something I've missed.
>>
>> -mike
>>
>>
>>
>> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland <te...@jotobjects.com>wrote:
>>
>>
>>> At one point in this thread it was mentioned that the benchmark ran much
>>> faster on a home computer than on an office computer and the reason for the
>>> difference was not obvious. Was that difference explained yet?
>>>
>>> What version of OpenJPA is the test using?
>>>
>>> - Paul
>>>
>>>
>>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
>>>
>>>
>>>> Shubbis and Nitish,
>>>> Thanks for your efforts. So, to clarify -- all implementations are using
>>>> similar configurations (ie. connection pooling, caching, enhancement,
>>>> etc)?
>>>> But, the OpenJPA performance is still 3 times slower than the
>>>> competitors?
>>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
>>>> would
>>>> expect some overhead as compared to iBatis and/or straight JDBC, but
>>>> OpenJPA
>>>> should be competitive (and beat) the Hibernates and EclipseLinks... Very
>>>> frustrating. When we do our comparisons with the industry benchmarks
>>>> (Trade
>>>> and SpecJApp), OpenJPA is extremely competitive.
>>>>
>>>> I have not closely examined your benchmark project, so I don't know how
>>>> it
>>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
>>>> topic?
>>>>
>>>> One other thought... Just to prove that the enhancement processing is
>>>> being
>>>> done and you're not falling into the sub-classing support, could you run
>>>> with the following property? This will cause your application to
>>>> error-off
>>>> if your Entities are not byte-code enhanced. We will not fall into the
>>>> sub-classing support which greatly affects the performance.
>>>>
>>>> <property name="openjpa.RuntimeUnenhancedClasses"
>>>> value="warn"/>
>>>>
>>>> It really seems that you are trying to do a fair comparison, and I
>>>> greatly
>>>> appreciate your efforts. The last time one of these comparisons was
>>>> posted,
>>>> the benchmark code and process was flawed. So, I am pleased to see the
>>>> efforts associated with this exercise.
>>>>
>>>> Our performance lead is out having a baby, so we haven't been able to dig
>>>> into your benchmark to the extent that we would like. If we can verify
>>>> that
>>>> the enhancement processing is happening, that would be good input.
>>>> Thanks
>>>> for your patience. What kind of timeframe are you under for posting this
>>>> benchmark?
>>>>
>>>> Thanks,
>>>> Kevin
>>>>
>>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Since we decided to go with vanilla installations of alle the frameworks
>>>>> we
>>>>> have not added the connection pool feature to OpenJPA, until now.
>>>>>
>>>>> The results are sadly not that great. Yes, it's faster and it doesn't
>>>>> run
>>>>> out of connections like before, BUT it's still 3, yes, -three- times
>>>>> slower
>>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>>>>> entities with many relations.
>>>>>
>>>>> Clearly this is not the kind of results I was hoping for and I'm quite
>>>>> perplexed as to what to do.
>>>>>
>>>>> Shubbis
>>>>>
>>>>>
>>>>> Nitish Kumar wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi subbis,
>>>>>> If I let the iteration loop over 5000, I get that exception, It
>>>>>> seems (I am not sure) openjpa is creating a new connection and after a
>>>>>> while mysql runs out of connection. I tried the same code and iteration
>>>>>> loop with a connection pool and it works fine. That should get you
>>>>>> moving as of now, till someone from Open JPA team looks into the issue.
>>>>>>
>>>>>> Thanks and Regards,
>>>>>> Nitish Kumar
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
> -------------------------------------------------------------------------------------------------------------------------
> "The information contained in this e-mail transmission is confidential and may be privileged. It is intended only for the
> addressee(s) stated above. If you are not an addressee, any use, dissemination, distribution, publication, or copying of
> the information contained in this e-mail is strictly prohibited. If you have received this e-mail in error, please
> immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender and delete the e-mail from your system.
> If you do not want to receive our emails please let us know so that we may delete you from our email list. Proteans
> Software Solutions and its parent group ("CAMO Group") do not accept liability for damage caused by this email, and may
> monitor email traffic."
> -------------------------------------------------------------------------------------------------------------------------
>
RE: Slow performance with OpenJPA when selecting from a ManyToMany relation.
Posted by Nitish Kumar <Ni...@proteans.com>.
Hi Michael,
The connection retain mode property makes the numbers almost same, but I am a little confused. Shouldnt this be the default behavior of Entity Manager? Typically I would have the entity manager tied up to the transaction (JTA or Spring), so I would expect Entity Manager to hold the connection always.
Thanks and Regards,
Nitish Kumar
-----Original Message-----
From: Michael Dick [mailto:michael.d.dick@gmail.com]
Sent: Sat 3/21/2009 1:55 AM
To: users@openjpa.apache.org
Subject: Re: Slow performance with OpenJPA when selecting from a ManyToMany relation.
Hi all,
As Paul pointed out privately I didn't indicate which versions of OpenJPA I
was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT primarily.
I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't much
difference though so reduced the scope to 1.2 and trunk.
The testcase uses a single EntityManager instance to issue a batch of findBy
operations. In OpenJPA each findBy (or any query for that matter) obtains a
connection from the connection pool and returns it after getting the
results. So we're spending a lot of time moving the connection to and from
the pool (some cleanup is done along the way).
Fortunately this behavior can be configured with the
openjpa.ConnectionRetainMode property. Setting it to "always" causes the
EntityManager to hold on to a single connection until the EntityManager
closes. Obviously this setting introduces the possibility of exhausting the
connection pool if num_entitymanagers > max_connections, but for this
benchmark it's safe to try.
Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop at
100 - 100,000 iterations. In addition I removed the
openjpa.jdbc.SynchronizeMappings property from the example (it's extraneous
once the tables are created anyway).Another option I enabled that made some
difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
has some pstmt caching as well, but that could be faulty - in which case
I'll disable it in dbcp.
Here's the entire set of properties I'm using :
properties.put("openjpa.Log", "DefaultLevel=FATAL");
properties.put("openjpa.RuntimeUnenhancedClasses", "unsupported");
properties.put("openjpa.ConnectionRetainMode", "always");
properties.put("openjpa.ConnectionDriverName",
"org.apache.commons.dbcp.BasicDataSource");
properties.put("openjpa.ConnectionProperties", String.format(
"DriverClassName=%s, Url=%s, username=%s, password=%s,"
+ " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
+ ", poolPreparedStatements=true"
, JDBC_DRIVER, JDBC_URL, JDBC_USER,
JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
EntityManagerFactory factory =
Persistence.createEntityManagerFactory("OpenJPAPU", properties);
MIN_CON = 1, MAX_CON=10.
Shubbis, could you try running something similar and see if you get the same
results?
-mike
On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick <mi...@gmail.com>wrote:
> Hi, I took a quick run with the source code from the RAR Shubbis attached
> earlier (thanks BTW).
>
> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt EclipseLink
> is doing better (certainly not 3x) based solely on the SQL.
>
> So I started digging deeper and on my laptop (not to be confused with any
> sort of "real" benchmark) there's a sweet spot around 100 iterations. Under
> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over 125
> iterations EclipseLink starts pulling ahead.
>
> Environment :
> * Entities were enhanced by the PCEnhancer tool prior to running the tests.
>
> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
> the same settings. EclipseLink's pool and commons-dbcp weren't an easy 1:1
> match, so I might have some investigation to do there.
> * MySQL Connector for Java v 5.1.7.
> * MySQL database running locally, Version: 5.0.67-0ubuntu6
> * Tests executed in Eclipse, YMMV outside of Eclipse.
> * Sun JDK 5 java full version "1.5.0_15-b04"
>
> I have done a lot of hacking about with the sample application but I don't
> think I've violated the intent of the exercise. I'll upload the app to a
> jira shortly.
>
> The relevant code is in my pastebin at these links :
> persistence.xml : http://miked.pastebin.com/m490814b7
> test01.java : http://miked.pastebin.com/m7d3df62f
> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
>
> I highlighted the changed lines in WarehouseDAO, but missed it on the
> others (too many lines to highlight accurately.
>
> I'm still looking, but thought this was worth sharing in case someone else
> sees something I've missed.
>
> -mike
>
>
>
> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland <te...@jotobjects.com>wrote:
>
>>
>> At one point in this thread it was mentioned that the benchmark ran much
>> faster on a home computer than on an office computer and the reason for the
>> difference was not obvious. Was that difference explained yet?
>>
>> What version of OpenJPA is the test using?
>>
>> - Paul
>>
>>
>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
>>
>>> Shubbis and Nitish,
>>> Thanks for your efforts. So, to clarify -- all implementations are using
>>> similar configurations (ie. connection pooling, caching, enhancement,
>>> etc)?
>>> But, the OpenJPA performance is still 3 times slower than the
>>> competitors?
>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
>>> would
>>> expect some overhead as compared to iBatis and/or straight JDBC, but
>>> OpenJPA
>>> should be competitive (and beat) the Hibernates and EclipseLinks... Very
>>> frustrating. When we do our comparisons with the industry benchmarks
>>> (Trade
>>> and SpecJApp), OpenJPA is extremely competitive.
>>>
>>> I have not closely examined your benchmark project, so I don't know how
>>> it
>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
>>> topic?
>>>
>>> One other thought... Just to prove that the enhancement processing is
>>> being
>>> done and you're not falling into the sub-classing support, could you run
>>> with the following property? This will cause your application to
>>> error-off
>>> if your Entities are not byte-code enhanced. We will not fall into the
>>> sub-classing support which greatly affects the performance.
>>>
>>> <property name="openjpa.RuntimeUnenhancedClasses"
>>> value="warn"/>
>>>
>>> It really seems that you are trying to do a fair comparison, and I
>>> greatly
>>> appreciate your efforts. The last time one of these comparisons was
>>> posted,
>>> the benchmark code and process was flawed. So, I am pleased to see the
>>> efforts associated with this exercise.
>>>
>>> Our performance lead is out having a baby, so we haven't been able to dig
>>> into your benchmark to the extent that we would like. If we can verify
>>> that
>>> the enhancement processing is happening, that would be good input.
>>> Thanks
>>> for your patience. What kind of timeframe are you under for posting this
>>> benchmark?
>>>
>>> Thanks,
>>> Kevin
>>>
>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
>>> wrote:
>>>
>>>
>>>
>>>> Since we decided to go with vanilla installations of alle the frameworks
>>>> we
>>>> have not added the connection pool feature to OpenJPA, until now.
>>>>
>>>> The results are sadly not that great. Yes, it's faster and it doesn't
>>>> run
>>>> out of connections like before, BUT it's still 3, yes, -three- times
>>>> slower
>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>>>> entities with many relations.
>>>>
>>>> Clearly this is not the kind of results I was hoping for and I'm quite
>>>> perplexed as to what to do.
>>>>
>>>> Shubbis
>>>>
>>>>
>>>> Nitish Kumar wrote:
>>>>
>>>>
>>>>> Hi subbis,
>>>>> If I let the iteration loop over 5000, I get that exception, It
>>>>> seems (I am not sure) openjpa is creating a new connection and after a
>>>>> while mysql runs out of connection. I tried the same code and iteration
>>>>> loop with a connection pool and it works fine. That should get you
>>>>> moving as of now, till someone from Open JPA team looks into the issue.
>>>>>
>>>>> Thanks and Regards,
>>>>> Nitish Kumar
>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
-------------------------------------------------------------------------------------------------------------------------
"The information contained in this e-mail transmission is confidential and may be privileged. It is intended only for the
addressee(s) stated above. If you are not an addressee, any use, dissemination, distribution, publication, or copying of
the information contained in this e-mail is strictly prohibited. If you have received this e-mail in error, please
immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender and delete the e-mail from your system.
If you do not want to receive our emails please let us know so that we may delete you from our email list. Proteans
Software Solutions and its parent group ("CAMO Group") do not accept liability for damage caused by this email, and may
monitor email traffic."
-------------------------------------------------------------------------------------------------------------------------
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Michael Dick <mi...@gmail.com>.
Hi all,
As Paul pointed out privately I didn't indicate which versions of OpenJPA I
was using. I've been testing with 1.2.0, 1.2.1 and 2.0.0-SNAPSHOT primarily.
I also ran with 1.3.0-SNAPSHOT, and 1.0.3 for comparison - there wasn't much
difference though so reduced the scope to 1.2 and trunk.
The testcase uses a single EntityManager instance to issue a batch of findBy
operations. In OpenJPA each findBy (or any query for that matter) obtains a
connection from the connection pool and returns it after getting the
results. So we're spending a lot of time moving the connection to and from
the pool (some cleanup is done along the way).
Fortunately this behavior can be configured with the
openjpa.ConnectionRetainMode property. Setting it to "always" causes the
EntityManager to hold on to a single connection until the EntityManager
closes. Obviously this setting introduces the possibility of exhausting the
connection pool if num_entitymanagers > max_connections, but for this
benchmark it's safe to try.
Setting ConnectionRetainMode gave OpenJPA equivalent times on my laptop at
100 - 100,000 iterations. In addition I removed the
openjpa.jdbc.SynchronizeMappings property from the example (it's extraneous
once the tables are created anyway).Another option I enabled that made some
difference was preparedStatementCaching in dbcp. I'm assuming EclipseLink
has some pstmt caching as well, but that could be faulty - in which case
I'll disable it in dbcp.
Here's the entire set of properties I'm using :
properties.put("openjpa.Log", "DefaultLevel=FATAL");
properties.put("openjpa.RuntimeUnenhancedClasses", "unsupported");
properties.put("openjpa.ConnectionRetainMode", "always");
properties.put("openjpa.ConnectionDriverName",
"org.apache.commons.dbcp.BasicDataSource");
properties.put("openjpa.ConnectionProperties", String.format(
"DriverClassName=%s, Url=%s, username=%s, password=%s,"
+ " MaxActive=%s, MaxIdle=%s, MinIdle=%s, MaxWait=%s"
+ ", poolPreparedStatements=true"
, JDBC_DRIVER, JDBC_URL, JDBC_USER,
JDBC_PASSWORD, MAX_CON, MIN_CON, MIN_CON, "1000"));
EntityManagerFactory factory =
Persistence.createEntityManagerFactory("OpenJPAPU", properties);
MIN_CON = 1, MAX_CON=10.
Shubbis, could you try running something similar and see if you get the same
results?
-mike
On Fri, Mar 20, 2009 at 8:46 AM, Michael Dick <mi...@gmail.com>wrote:
> Hi, I took a quick run with the source code from the RAR Shubbis attached
> earlier (thanks BTW).
>
> The SQL we execute for this findBy is SELECT t0.warehouseName FROM
> Warehouse t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt EclipseLink
> is doing better (certainly not 3x) based solely on the SQL.
>
> So I started digging deeper and on my laptop (not to be confused with any
> sort of "real" benchmark) there's a sweet spot around 100 iterations. Under
> 100 OpenJPA is faster. Between 100 and 125 they're comparable, and over 125
> iterations EclipseLink starts pulling ahead.
>
> Environment :
> * Entities were enhanced by the PCEnhancer tool prior to running the tests.
>
> * Connection pooling is enabled for EclipseLink and OpenJPA with roughly
> the same settings. EclipseLink's pool and commons-dbcp weren't an easy 1:1
> match, so I might have some investigation to do there.
> * MySQL Connector for Java v 5.1.7.
> * MySQL database running locally, Version: 5.0.67-0ubuntu6
> * Tests executed in Eclipse, YMMV outside of Eclipse.
> * Sun JDK 5 java full version "1.5.0_15-b04"
>
> I have done a lot of hacking about with the sample application but I don't
> think I've violated the intent of the exercise. I'll upload the app to a
> jira shortly.
>
> The relevant code is in my pastebin at these links :
> persistence.xml : http://miked.pastebin.com/m490814b7
> test01.java : http://miked.pastebin.com/m7d3df62f
> WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
>
> I highlighted the changed lines in WarehouseDAO, but missed it on the
> others (too many lines to highlight accurately.
>
> I'm still looking, but thought this was worth sharing in case someone else
> sees something I've missed.
>
> -mike
>
>
>
> On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland <te...@jotobjects.com>wrote:
>
>>
>> At one point in this thread it was mentioned that the benchmark ran much
>> faster on a home computer than on an office computer and the reason for the
>> difference was not obvious. Was that difference explained yet?
>>
>> What version of OpenJPA is the test using?
>>
>> - Paul
>>
>>
>> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
>>
>>> Shubbis and Nitish,
>>> Thanks for your efforts. So, to clarify -- all implementations are using
>>> similar configurations (ie. connection pooling, caching, enhancement,
>>> etc)?
>>> But, the OpenJPA performance is still 3 times slower than the
>>> competitors?
>>> In all of the scenarios? Or, just with this ManyToMany scenario? I
>>> would
>>> expect some overhead as compared to iBatis and/or straight JDBC, but
>>> OpenJPA
>>> should be competitive (and beat) the Hibernates and EclipseLinks... Very
>>> frustrating. When we do our comparisons with the industry benchmarks
>>> (Trade
>>> and SpecJApp), OpenJPA is extremely competitive.
>>>
>>> I have not closely examined your benchmark project, so I don't know how
>>> it
>>> compares to Trade and/or SpecJApp work loads. Any thoughts on this
>>> topic?
>>>
>>> One other thought... Just to prove that the enhancement processing is
>>> being
>>> done and you're not falling into the sub-classing support, could you run
>>> with the following property? This will cause your application to
>>> error-off
>>> if your Entities are not byte-code enhanced. We will not fall into the
>>> sub-classing support which greatly affects the performance.
>>>
>>> <property name="openjpa.RuntimeUnenhancedClasses"
>>> value="warn"/>
>>>
>>> It really seems that you are trying to do a fair comparison, and I
>>> greatly
>>> appreciate your efforts. The last time one of these comparisons was
>>> posted,
>>> the benchmark code and process was flawed. So, I am pleased to see the
>>> efforts associated with this exercise.
>>>
>>> Our performance lead is out having a baby, so we haven't been able to dig
>>> into your benchmark to the extent that we would like. If we can verify
>>> that
>>> the enhancement processing is happening, that would be good input.
>>> Thanks
>>> for your patience. What kind of timeframe are you under for posting this
>>> benchmark?
>>>
>>> Thanks,
>>> Kevin
>>>
>>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
>>> wrote:
>>>
>>>
>>>
>>>> Since we decided to go with vanilla installations of alle the frameworks
>>>> we
>>>> have not added the connection pool feature to OpenJPA, until now.
>>>>
>>>> The results are sadly not that great. Yes, it's faster and it doesn't
>>>> run
>>>> out of connections like before, BUT it's still 3, yes, -three- times
>>>> slower
>>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>>>> entities with many relations.
>>>>
>>>> Clearly this is not the kind of results I was hoping for and I'm quite
>>>> perplexed as to what to do.
>>>>
>>>> Shubbis
>>>>
>>>>
>>>> Nitish Kumar wrote:
>>>>
>>>>
>>>>> Hi subbis,
>>>>> If I let the iteration loop over 5000, I get that exception, It
>>>>> seems (I am not sure) openjpa is creating a new connection and after a
>>>>> while mysql runs out of connection. I tried the same code and iteration
>>>>> loop with a connection pool and it works fine. That should get you
>>>>> moving as of now, till someone from Open JPA team looks into the issue.
>>>>>
>>>>> Thanks and Regards,
>>>>> Nitish Kumar
>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Michael Dick <mi...@gmail.com>.
Hi, I took a quick run with the source code from the RAR Shubbis attached
earlier (thanks BTW).
The SQL we execute for this findBy is SELECT t0.warehouseName FROM Warehouse
t0 WHERE t0.warehouseNr = ?. Pretty basic, and I doubt EclipseLink is doing
better (certainly not 3x) based solely on the SQL.
So I started digging deeper and on my laptop (not to be confused with any
sort of "real" benchmark) there's a sweet spot around 100 iterations. Under
100 OpenJPA is faster. Between 100 and 125 they're comparable, and over 125
iterations EclipseLink starts pulling ahead.
Environment :
* Entities were enhanced by the PCEnhancer tool prior to running the tests.
* Connection pooling is enabled for EclipseLink and OpenJPA with roughly the
same settings. EclipseLink's pool and commons-dbcp weren't an easy 1:1
match, so I might have some investigation to do there.
* MySQL Connector for Java v 5.1.7.
* MySQL database running locally, Version: 5.0.67-0ubuntu6
* Tests executed in Eclipse, YMMV outside of Eclipse.
* Sun JDK 5 java full version "1.5.0_15-b04"
I have done a lot of hacking about with the sample application but I don't
think I've violated the intent of the exercise. I'll upload the app to a
jira shortly.
The relevant code is in my pastebin at these links :
persistence.xml : http://miked.pastebin.com/m490814b7
test01.java : http://miked.pastebin.com/m7d3df62f
WarehouseDAO.java : http://miked.pastebin.com/m49ab9a0e
I highlighted the changed lines in WarehouseDAO, but missed it on the others
(too many lines to highlight accurately.
I'm still looking, but thought this was worth sharing in case someone else
sees something I've missed.
-mike
On Thu, Mar 19, 2009 at 10:53 AM, Paul Copeland <te...@jotobjects.com> wrote:
>
> At one point in this thread it was mentioned that the benchmark ran much
> faster on a home computer than on an office computer and the reason for the
> difference was not obvious. Was that difference explained yet?
>
> What version of OpenJPA is the test using?
>
> - Paul
>
>
> On 3/19/2009 7:44 AM, Kevin Sutter wrote:
>
>> Shubbis and Nitish,
>> Thanks for your efforts. So, to clarify -- all implementations are using
>> similar configurations (ie. connection pooling, caching, enhancement,
>> etc)?
>> But, the OpenJPA performance is still 3 times slower than the competitors?
>> In all of the scenarios? Or, just with this ManyToMany scenario? I would
>> expect some overhead as compared to iBatis and/or straight JDBC, but
>> OpenJPA
>> should be competitive (and beat) the Hibernates and EclipseLinks... Very
>> frustrating. When we do our comparisons with the industry benchmarks
>> (Trade
>> and SpecJApp), OpenJPA is extremely competitive.
>>
>> I have not closely examined your benchmark project, so I don't know how it
>> compares to Trade and/or SpecJApp work loads. Any thoughts on this topic?
>>
>> One other thought... Just to prove that the enhancement processing is
>> being
>> done and you're not falling into the sub-classing support, could you run
>> with the following property? This will cause your application to
>> error-off
>> if your Entities are not byte-code enhanced. We will not fall into the
>> sub-classing support which greatly affects the performance.
>>
>> <property name="openjpa.RuntimeUnenhancedClasses"
>> value="warn"/>
>>
>> It really seems that you are trying to do a fair comparison, and I greatly
>> appreciate your efforts. The last time one of these comparisons was
>> posted,
>> the benchmark code and process was flawed. So, I am pleased to see the
>> efforts associated with this exercise.
>>
>> Our performance lead is out having a baby, so we haven't been able to dig
>> into your benchmark to the extent that we would like. If we can verify
>> that
>> the enhancement processing is happening, that would be good input. Thanks
>> for your patience. What kind of timeframe are you under for posting this
>> benchmark?
>>
>> Thanks,
>> Kevin
>>
>> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
>> wrote:
>>
>>
>>
>>> Since we decided to go with vanilla installations of alle the frameworks
>>> we
>>> have not added the connection pool feature to OpenJPA, until now.
>>>
>>> The results are sadly not that great. Yes, it's faster and it doesn't run
>>> out of connections like before, BUT it's still 3, yes, -three- times
>>> slower
>>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>>> entities with many relations.
>>>
>>> Clearly this is not the kind of results I was hoping for and I'm quite
>>> perplexed as to what to do.
>>>
>>> Shubbis
>>>
>>>
>>> Nitish Kumar wrote:
>>>
>>>
>>>> Hi subbis,
>>>> If I let the iteration loop over 5000, I get that exception, It
>>>> seems (I am not sure) openjpa is creating a new connection and after a
>>>> while mysql runs out of connection. I tried the same code and iteration
>>>> loop with a connection pool and it works fine. That should get you
>>>> moving as of now, till someone from Open JPA team looks into the issue.
>>>>
>>>> Thanks and Regards,
>>>> Nitish Kumar
>>>>
>>>>
>>>>
>>> --
>>> View this message in context:
>>>
>>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Pinaki Poddar <pp...@apache.org>.
> It took 2.3 sec
That matches with my numbers. If you use a connection pool, it will come
down to ~0.75 seconds.
> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
> Nice work ;)
This is my very first attempt to learn how to build plugins. I think it is
beginner's luck :)
But seriously, thank you for using it and verifying that it works.
Shubbis wrote:
>
> Ok, I still dont know what the problem is, but it seems like its not
> OpenJPA's fault (i think).
> I just took the whole project home with me, and installed it on my own
> laptop in a new workspace, and what do you know.. It took 2.3 sec.
> compared to the 12-15 sec.
>
> Now, I still don't know the root of the cause, since we have tried it on
> multiple computers at work, but at least this confirms that the project
> itself is working.
>
> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
> Nice work ;)
>
> Shubbis
>
> PS: adding the project if anyone wants to see. This is without all Ant and
> OpenJPA jar files as they were to big to upload here.
>
> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
> OpenJPASISTETEST.rar
>
>
> Pinaki Poddar wrote:
>>
>> Hi,
>>> Maybe someone could post an example of their build.xml file so that i
>>> could try it. See if maybe its my
>>> enhancing thats the problem.
>>
>> If you are an Eclipse IDE user, you can try a plugin [1] that keeps
>> your classes enhanced always. Or you may be better of with Ant builds as
>> Mike had provided.
>>
>> In either case, Enhancer displays log messages and running it twice
>> perhaps will confirm -- because second time it will say: 'class X is
>> already persistence-capable. Ignoring...' etc.
>>
>> [1] http://people.apache.org/~ppoddar/eclipse/
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2493300.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Pinaki Poddar <pp...@apache.org>.
> PS: I still could not make the enhancer work with ANT
What was the problem?
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2498707.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Slow performance with OpenJPA when selecting from a ManyToMany relation.
Posted by Nitish Kumar <Ni...@proteans.com>.
Yes Pinaki,
Its just that I realized today that hibernate uses a built in
connection pool, so adding a connection pool to open Jpa would not bias
the comparison.
Further to Kevin's point, I am not planning to publish any benchmark, I
am just evaluation openJpa as an alternative to hibernate for my future
projects. I already have a lots of positives in favor of open jpa, guess
performance was one of the widely publicized concerns for open jpa. So I
decided to get my hands dirty and find out for myself.
Thanks and Regards,
Nitish Kumar
-----Original Message-----
From: Pinaki Poddar [mailto:ppoddar@apache.org]
Sent: Thursday, March 19, 2009 8:46 PM
To: users@openjpa.apache.org
Subject: RE: Slow performance with OpenJPA when selecting from a
ManyToMany relation.
> Once you configure Open Jpa with a connection pool as mentioned here
the
numbers drop drastically.
That was the first thing mentioned while we looked at this issue several
days ago.
> I ran the Wearhouse-StorageCategory model you have posted (thank you
for
> a clean test). Against
> 500 categories and 200 wearhouses and a cardinality of 10 categories
per
> wearhouse. The domain
> classes were enhanced at build-time. The database is MySQL and the
tests
> ran in my pedestrian
> laptop. Here are the results for finding Wearhouses 500 times in a
loop.
Without connection pool : 2360 ms.
With connection pool : 734ms
Few comments:
1. If performance is higher priority than ordering, consider using
Set<>
instead of List<>
2. Consider using a connection pool, if possible [1]
[1]
http://openjpa.apache.org/faq.html#FAQ-HowdoIenableconnectionpoolinginOp
enJPA%253F
Regards --
Nitish Kumar wrote:
>
> Hi guys,
> I just realized that Hibernate has its own connection pool which
> it uses, Once you configure Open Jpa with a connection pool as
mentioned
> here
>
http://webspherepersistence.blogspot.com/2009/01/jpa-connection-pooling.
> html , the numbers drop drastically. Hope that helps to do a fair
> comparison.
>
> Thanks and Regards,
> Nitish Kumar
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Wednesday, March 18, 2009 10:17 PM
> To: users@openjpa.apache.org
> Subject: Re: Slow performance with OpenJPA when selecting from a
> ManyToMany relation.
>
> One other interesting bit of information... I just heard that
> EclipseLink
> runs with a data cache enabled by default, while OpenJPA and Hibernate
> do
> not. Although this setting may not get us completely out of this
> ManyToMany
> performance hole, it is something to be aware of as these performance
> benchmarks are done...
>
> Kevin
>
> On Wed, Mar 18, 2009 at 6:59 AM, Nitish Kumar
> <Ni...@proteans.com>wrote:
>
>> Hi,
>> My stats on this, I just ran it on Win XP (JRE 1.5.0_14) and
>> local MySQL, took an average of 3.8 sec to complete 500 iterations.
>> Removed the many to many association, doesn't affect the numbers
much.
>> Make the fetch as eager and it takes 4.2 sec.
>>
>> Something weird here, added the setting <property
>> name="openjpa.jdbc.DBDictionary" value="JoinSyntax=traditional"/> and
> it
>> goes up to 7.2 sec with eager and 4 sec with lazy.
>>
>> PS: I still could not make the enhancer work with ANT so I wrote a
>> simple class
>>
>> public static void main(String[] args) {
>> Collection listFiles = FileUtils.listFiles(new
>> File("./src/model"),
>> new String[] { "java" }, true);
>> for (Object object : listFiles) {
>> File file = (File) object;
>> String[] args1 = new String[] { file.getPath()
>> };
>> PCEnhancer.main(args1);
>> }
>> }
>>
>> it has a dependency on commons-io but works great.
>>
>> Thanks and Regards,
>> Nitish Kumar
>>
>> -----Original Message-----
>> From: Shubbis [mailto:marius.jones@broadpark.no]
>> Sent: Wednesday, March 18, 2009 12:01 AM
>> To: users@openjpa.apache.org
>> Subject: Re: Slow performance with OpenJPA when selecting from a
>> ManyToMany relation.
>>
>>
>> Ok, I still dont know what the problem is, but it seems like its not
>> OpenJPA's fault (i think).
>> I just took the whole project home with me, and installed it on my
own
>> laptop in a new workspace, and what do you know.. It took 2.3 sec.
>> compared
>> to the 12-15 sec.
>>
>> Now, I still don't know the root of the cause, since we have tried it
> on
>> multiple computers at work, but at least this confirms that the
> project
>> itself is working.
>>
>> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell.
> FYI.
>> Nice
>> work ;)
>>
>> Shubbis
>>
>> PS: adding the project if anyone wants to see. This is without all
Ant
>> and
>> OpenJPA jar files as they were to big to upload here.
>>
>> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
>> OpenJPASISTETEST.rar
>>
>>
>> Pinaki Poddar wrote:
>> >
>> > Hi,
>> >> Maybe someone could post an example of their build.xml file so
that
> i
>> >> could try it. See if maybe its my
>> >> enhancing thats the problem.
>> >
>> > If you are an Eclipse IDE user, you can try a plugin [1] that
> keeps
>> your
>> > classes enhanced always. Or you may be better of with Ant builds as
>> Mike
>> > had provided.
>> >
>> > In either case, Enhancer displays log messages and running it
> twice
>> > perhaps will confirm -- because second time it will say: 'class X
is
>> > already persistence-capable. Ignoring...' etc.
>> >
>> > [1]
>
http://people.apache.org/~ppoddar/eclipse/<http://people.apache.org/%7Ep
> poddar/eclipse/>
>> >
>> >
>>
>>
>>
>> --
>> View this message in context:
>>
>
http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a
>>
>
-ManyToMany-relation.-tp2466994p2493009.html<http://n2.nabble.com/Slow-p
>
erformance-with-OpenJPA-when-selecting-from-a%0A-ManyToMany-relation.-tp
> 2466994p2493009.html>
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>>
>>
>
------------------------------------------------------------------------
> -------------------------------------------------
>> "The information contained in this e-mail transmission is
confidential
> and
>> may be privileged. It is intended only for the
>> addressee(s) stated above. If you are not an addressee, any use,
>> dissemination, distribution, publication, or copying of
>> the information contained in this e-mail is strictly prohibited. If
> you
>> have received this e-mail in error, please
>> immediately notify us by telephone (+91 80 6618 6555), or e-mail the
> sender
>> and delete the e-mail from your system.
>> If you do not want to receive our emails please let us know so that
we
> may
>> delete you from our email list. Proteans
>> Software Solutions and its parent group ("CAMO Group") do not accept
>> liability for damage caused by this email, and may
>> monitor email traffic."
>>
>>
>
------------------------------------------------------------------------
> -------------------------------------------------
>>
>>
>
>
------------------------------------------------------------------------
-------------------------------------------------
> "The information contained in this e-mail transmission is confidential
and
> may be privileged. It is intended only for the
> addressee(s) stated above. If you are not an addressee, any use,
> dissemination, distribution, publication, or copying of
> the information contained in this e-mail is strictly prohibited. If
you
> have received this e-mail in error, please
> immediately notify us by telephone (+91 80 6618 6555), or e-mail the
> sender and delete the e-mail from your system.
> If you do not want to receive our emails please let us know so that we
may
> delete you from our email list. Proteans
> Software Solutions and its parent group ("CAMO Group") do not accept
> liability for damage caused by this email, and may
> monitor email traffic."
>
------------------------------------------------------------------------
-------------------------------------------------
>
>
>
-----
Pinaki Poddar http://ppoddar.blogspot.com/
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
--
View this message in context:
http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a
-ManyToMany-relation.-tp2466994p2503460.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
-------------------------------------------------------------------------------------------------------------------------
"The information contained in this e-mail transmission is confidential and may be privileged. It is intended only for the
addressee(s) stated above. If you are not an addressee, any use, dissemination, distribution, publication, or copying of
the information contained in this e-mail is strictly prohibited. If you have received this e-mail in error, please
immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender and delete the e-mail from your system.
If you do not want to receive our emails please let us know so that we may delete you from our email list. Proteans
Software Solutions and its parent group ("CAMO Group") do not accept liability for damage caused by this email, and may
monitor email traffic."
-------------------------------------------------------------------------------------------------------------------------
RE: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Pinaki Poddar <pp...@apache.org>.
> Once you configure Open Jpa with a connection pool as mentioned here the
numbers drop drastically.
That was the first thing mentioned while we looked at this issue several
days ago.
> I ran the Wearhouse-StorageCategory model you have posted (thank you for
> a clean test). Against
> 500 categories and 200 wearhouses and a cardinality of 10 categories per
> wearhouse. The domain
> classes were enhanced at build-time. The database is MySQL and the tests
> ran in my pedestrian
> laptop. Here are the results for finding Wearhouses 500 times in a loop.
Without connection pool : 2360 ms.
With connection pool : 734ms
Few comments:
1. If performance is higher priority than ordering, consider using Set<>
instead of List<>
2. Consider using a connection pool, if possible [1]
[1]
http://openjpa.apache.org/faq.html#FAQ-HowdoIenableconnectionpoolinginOpenJPA%253F
Regards --
Nitish Kumar wrote:
>
> Hi guys,
> I just realized that Hibernate has its own connection pool which
> it uses, Once you configure Open Jpa with a connection pool as mentioned
> here
> http://webspherepersistence.blogspot.com/2009/01/jpa-connection-pooling.
> html , the numbers drop drastically. Hope that helps to do a fair
> comparison.
>
> Thanks and Regards,
> Nitish Kumar
>
> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Wednesday, March 18, 2009 10:17 PM
> To: users@openjpa.apache.org
> Subject: Re: Slow performance with OpenJPA when selecting from a
> ManyToMany relation.
>
> One other interesting bit of information... I just heard that
> EclipseLink
> runs with a data cache enabled by default, while OpenJPA and Hibernate
> do
> not. Although this setting may not get us completely out of this
> ManyToMany
> performance hole, it is something to be aware of as these performance
> benchmarks are done...
>
> Kevin
>
> On Wed, Mar 18, 2009 at 6:59 AM, Nitish Kumar
> <Ni...@proteans.com>wrote:
>
>> Hi,
>> My stats on this, I just ran it on Win XP (JRE 1.5.0_14) and
>> local MySQL, took an average of 3.8 sec to complete 500 iterations.
>> Removed the many to many association, doesn't affect the numbers much.
>> Make the fetch as eager and it takes 4.2 sec.
>>
>> Something weird here, added the setting <property
>> name="openjpa.jdbc.DBDictionary" value="JoinSyntax=traditional"/> and
> it
>> goes up to 7.2 sec with eager and 4 sec with lazy.
>>
>> PS: I still could not make the enhancer work with ANT so I wrote a
>> simple class
>>
>> public static void main(String[] args) {
>> Collection listFiles = FileUtils.listFiles(new
>> File("./src/model"),
>> new String[] { "java" }, true);
>> for (Object object : listFiles) {
>> File file = (File) object;
>> String[] args1 = new String[] { file.getPath()
>> };
>> PCEnhancer.main(args1);
>> }
>> }
>>
>> it has a dependency on commons-io but works great.
>>
>> Thanks and Regards,
>> Nitish Kumar
>>
>> -----Original Message-----
>> From: Shubbis [mailto:marius.jones@broadpark.no]
>> Sent: Wednesday, March 18, 2009 12:01 AM
>> To: users@openjpa.apache.org
>> Subject: Re: Slow performance with OpenJPA when selecting from a
>> ManyToMany relation.
>>
>>
>> Ok, I still dont know what the problem is, but it seems like its not
>> OpenJPA's fault (i think).
>> I just took the whole project home with me, and installed it on my own
>> laptop in a new workspace, and what do you know.. It took 2.3 sec.
>> compared
>> to the 12-15 sec.
>>
>> Now, I still don't know the root of the cause, since we have tried it
> on
>> multiple computers at work, but at least this confirms that the
> project
>> itself is working.
>>
>> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell.
> FYI.
>> Nice
>> work ;)
>>
>> Shubbis
>>
>> PS: adding the project if anyone wants to see. This is without all Ant
>> and
>> OpenJPA jar files as they were to big to upload here.
>>
>> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
>> OpenJPASISTETEST.rar
>>
>>
>> Pinaki Poddar wrote:
>> >
>> > Hi,
>> >> Maybe someone could post an example of their build.xml file so that
> i
>> >> could try it. See if maybe its my
>> >> enhancing thats the problem.
>> >
>> > If you are an Eclipse IDE user, you can try a plugin [1] that
> keeps
>> your
>> > classes enhanced always. Or you may be better of with Ant builds as
>> Mike
>> > had provided.
>> >
>> > In either case, Enhancer displays log messages and running it
> twice
>> > perhaps will confirm -- because second time it will say: 'class X is
>> > already persistence-capable. Ignoring...' etc.
>> >
>> > [1]
> http://people.apache.org/~ppoddar/eclipse/<http://people.apache.org/%7Ep
> poddar/eclipse/>
>> >
>> >
>>
>>
>>
>> --
>> View this message in context:
>>
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a
>>
> -ManyToMany-relation.-tp2466994p2493009.html<http://n2.nabble.com/Slow-p
> erformance-with-OpenJPA-when-selecting-from-a%0A-ManyToMany-relation.-tp
> 2466994p2493009.html>
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>>
>>
> ------------------------------------------------------------------------
> -------------------------------------------------
>> "The information contained in this e-mail transmission is confidential
> and
>> may be privileged. It is intended only for the
>> addressee(s) stated above. If you are not an addressee, any use,
>> dissemination, distribution, publication, or copying of
>> the information contained in this e-mail is strictly prohibited. If
> you
>> have received this e-mail in error, please
>> immediately notify us by telephone (+91 80 6618 6555), or e-mail the
> sender
>> and delete the e-mail from your system.
>> If you do not want to receive our emails please let us know so that we
> may
>> delete you from our email list. Proteans
>> Software Solutions and its parent group ("CAMO Group") do not accept
>> liability for damage caused by this email, and may
>> monitor email traffic."
>>
>>
> ------------------------------------------------------------------------
> -------------------------------------------------
>>
>>
>
> -------------------------------------------------------------------------------------------------------------------------
> "The information contained in this e-mail transmission is confidential and
> may be privileged. It is intended only for the
> addressee(s) stated above. If you are not an addressee, any use,
> dissemination, distribution, publication, or copying of
> the information contained in this e-mail is strictly prohibited. If you
> have received this e-mail in error, please
> immediately notify us by telephone (+91 80 6618 6555), or e-mail the
> sender and delete the e-mail from your system.
> If you do not want to receive our emails please let us know so that we may
> delete you from our email list. Proteans
> Software Solutions and its parent group ("CAMO Group") do not accept
> liability for damage caused by this email, and may
> monitor email traffic."
> -------------------------------------------------------------------------------------------------------------------------
>
>
>
-----
Pinaki Poddar http://ppoddar.blogspot.com/
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503460.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Slow performance with OpenJPA when selecting from a ManyToMany relation.
Posted by Nitish Kumar <Ni...@proteans.com>.
Hi guys,
I just realized that Hibernate has its own connection pool which
it uses, Once you configure Open Jpa with a connection pool as mentioned
here
http://webspherepersistence.blogspot.com/2009/01/jpa-connection-pooling.
html , the numbers drop drastically. Hope that helps to do a fair
comparison.
Thanks and Regards,
Nitish Kumar
-----Original Message-----
From: Kevin Sutter [mailto:kwsutter@gmail.com]
Sent: Wednesday, March 18, 2009 10:17 PM
To: users@openjpa.apache.org
Subject: Re: Slow performance with OpenJPA when selecting from a
ManyToMany relation.
One other interesting bit of information... I just heard that
EclipseLink
runs with a data cache enabled by default, while OpenJPA and Hibernate
do
not. Although this setting may not get us completely out of this
ManyToMany
performance hole, it is something to be aware of as these performance
benchmarks are done...
Kevin
On Wed, Mar 18, 2009 at 6:59 AM, Nitish Kumar
<Ni...@proteans.com>wrote:
> Hi,
> My stats on this, I just ran it on Win XP (JRE 1.5.0_14) and
> local MySQL, took an average of 3.8 sec to complete 500 iterations.
> Removed the many to many association, doesn't affect the numbers much.
> Make the fetch as eager and it takes 4.2 sec.
>
> Something weird here, added the setting <property
> name="openjpa.jdbc.DBDictionary" value="JoinSyntax=traditional"/> and
it
> goes up to 7.2 sec with eager and 4 sec with lazy.
>
> PS: I still could not make the enhancer work with ANT so I wrote a
> simple class
>
> public static void main(String[] args) {
> Collection listFiles = FileUtils.listFiles(new
> File("./src/model"),
> new String[] { "java" }, true);
> for (Object object : listFiles) {
> File file = (File) object;
> String[] args1 = new String[] { file.getPath()
> };
> PCEnhancer.main(args1);
> }
> }
>
> it has a dependency on commons-io but works great.
>
> Thanks and Regards,
> Nitish Kumar
>
> -----Original Message-----
> From: Shubbis [mailto:marius.jones@broadpark.no]
> Sent: Wednesday, March 18, 2009 12:01 AM
> To: users@openjpa.apache.org
> Subject: Re: Slow performance with OpenJPA when selecting from a
> ManyToMany relation.
>
>
> Ok, I still dont know what the problem is, but it seems like its not
> OpenJPA's fault (i think).
> I just took the whole project home with me, and installed it on my own
> laptop in a new workspace, and what do you know.. It took 2.3 sec.
> compared
> to the 12-15 sec.
>
> Now, I still don't know the root of the cause, since we have tried it
on
> multiple computers at work, but at least this confirms that the
project
> itself is working.
>
> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell.
FYI.
> Nice
> work ;)
>
> Shubbis
>
> PS: adding the project if anyone wants to see. This is without all Ant
> and
> OpenJPA jar files as they were to big to upload here.
>
> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
> OpenJPASISTETEST.rar
>
>
> Pinaki Poddar wrote:
> >
> > Hi,
> >> Maybe someone could post an example of their build.xml file so that
i
> >> could try it. See if maybe its my
> >> enhancing thats the problem.
> >
> > If you are an Eclipse IDE user, you can try a plugin [1] that
keeps
> your
> > classes enhanced always. Or you may be better of with Ant builds as
> Mike
> > had provided.
> >
> > In either case, Enhancer displays log messages and running it
twice
> > perhaps will confirm -- because second time it will say: 'class X is
> > already persistence-capable. Ignoring...' etc.
> >
> > [1]
http://people.apache.org/~ppoddar/eclipse/<http://people.apache.org/%7Ep
poddar/eclipse/>
> >
> >
>
>
>
> --
> View this message in context:
>
http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a
>
-ManyToMany-relation.-tp2466994p2493009.html<http://n2.nabble.com/Slow-p
erformance-with-OpenJPA-when-selecting-from-a%0A-ManyToMany-relation.-tp
2466994p2493009.html>
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
>
>
------------------------------------------------------------------------
-------------------------------------------------
> "The information contained in this e-mail transmission is confidential
and
> may be privileged. It is intended only for the
> addressee(s) stated above. If you are not an addressee, any use,
> dissemination, distribution, publication, or copying of
> the information contained in this e-mail is strictly prohibited. If
you
> have received this e-mail in error, please
> immediately notify us by telephone (+91 80 6618 6555), or e-mail the
sender
> and delete the e-mail from your system.
> If you do not want to receive our emails please let us know so that we
may
> delete you from our email list. Proteans
> Software Solutions and its parent group ("CAMO Group") do not accept
> liability for damage caused by this email, and may
> monitor email traffic."
>
>
------------------------------------------------------------------------
-------------------------------------------------
>
>
-------------------------------------------------------------------------------------------------------------------------
"The information contained in this e-mail transmission is confidential and may be privileged. It is intended only for the
addressee(s) stated above. If you are not an addressee, any use, dissemination, distribution, publication, or copying of
the information contained in this e-mail is strictly prohibited. If you have received this e-mail in error, please
immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender and delete the e-mail from your system.
If you do not want to receive our emails please let us know so that we may delete you from our email list. Proteans
Software Solutions and its parent group ("CAMO Group") do not accept liability for damage caused by this email, and may
monitor email traffic."
-------------------------------------------------------------------------------------------------------------------------
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Hi Kevin,
All the implementations are run using each framework's default settings.
With only a few exceptions.
For instance, openjpa needs to enhance files in order to perform as expected
etc. Small changes that do not require in depth knowledge of the frameworks
are allowed.
Not all scenarios are affected, it seems that only test cases that involve
quite a large number of relations is the root of the problem.
I'm afraid i don't have any thought on Trade or SpecJApp as I have no
experience with either.
I ran with the property settings you posted and can inform you that I got no
warnings. We are enhanced ;)
I also appreciate the efforts to help make this project work as intended. We
have one framework as a main priority each, and as you might be able to
tell, i got OpenJPA. So this is kind of my "baby" during this whole exercise
and believe me, I want it to work just as much as you guys.
Like i said to Michael, his suggestion increased the performance and might
be the solution, but I can not be sure untill i get back to the office.
I will of course reply with updates.
Shubbis
Kevin Sutter wrote:
>
> Shubbis and Nitish,
> Thanks for your efforts. So, to clarify -- all implementations are using
> similar configurations (ie. connection pooling, caching, enhancement,
> etc)?
> But, the OpenJPA performance is still 3 times slower than the competitors?
> In all of the scenarios? Or, just with this ManyToMany scenario? I would
> expect some overhead as compared to iBatis and/or straight JDBC, but
> OpenJPA
> should be competitive (and beat) the Hibernates and EclipseLinks... Very
> frustrating. When we do our comparisons with the industry benchmarks
> (Trade
> and SpecJApp), OpenJPA is extremely competitive.
>
> I have not closely examined your benchmark project, so I don't know how it
> compares to Trade and/or SpecJApp work loads. Any thoughts on this topic?
>
> One other thought... Just to prove that the enhancement processing is
> being
> done and you're not falling into the sub-classing support, could you run
> with the following property? This will cause your application to
> error-off
> if your Entities are not byte-code enhanced. We will not fall into the
> sub-classing support which greatly affects the performance.
>
> <property name="openjpa.RuntimeUnenhancedClasses"
> value="warn"/>
>
> It really seems that you are trying to do a fair comparison, and I greatly
> appreciate your efforts. The last time one of these comparisons was
> posted,
> the benchmark code and process was flawed. So, I am pleased to see the
> efforts associated with this exercise.
>
> Our performance lead is out having a baby, so we haven't been able to dig
> into your benchmark to the extent that we would like. If we can verify
> that
> the enhancement processing is happening, that would be good input. Thanks
> for your patience. What kind of timeframe are you under for posting this
> benchmark?
>
> Thanks,
> Kevin
>
> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no>
> wrote:
>
>>
>> Since we decided to go with vanilla installations of alle the frameworks
>> we
>> have not added the connection pool feature to OpenJPA, until now.
>>
>> The results are sadly not that great. Yes, it's faster and it doesn't run
>> out of connections like before, BUT it's still 3, yes, -three- times
>> slower
>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>> entities with many relations.
>>
>> Clearly this is not the kind of results I was hoping for and I'm quite
>> perplexed as to what to do.
>>
>> Shubbis
>>
>>
>> Nitish Kumar wrote:
>> >
>> > Hi subbis,
>> > If I let the iteration loop over 5000, I get that exception, It
>> > seems (I am not sure) openjpa is creating a new connection and after a
>> > while mysql runs out of connection. I tried the same code and iteration
>> > loop with a connection pool and it works fine. That should get you
>> > moving as of now, till someone from Open JPA team looks into the issue.
>> >
>> > Thanks and Regards,
>> > Nitish Kumar
>> >
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2517019.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Paul Copeland <te...@jotobjects.com>.
At one point in this thread it was mentioned that the benchmark ran much
faster on a home computer than on an office computer and the reason for
the difference was not obvious. Was that difference explained yet?
What version of OpenJPA is the test using?
- Paul
On 3/19/2009 7:44 AM, Kevin Sutter wrote:
> Shubbis and Nitish,
> Thanks for your efforts. So, to clarify -- all implementations are using
> similar configurations (ie. connection pooling, caching, enhancement, etc)?
> But, the OpenJPA performance is still 3 times slower than the competitors?
> In all of the scenarios? Or, just with this ManyToMany scenario? I would
> expect some overhead as compared to iBatis and/or straight JDBC, but OpenJPA
> should be competitive (and beat) the Hibernates and EclipseLinks... Very
> frustrating. When we do our comparisons with the industry benchmarks (Trade
> and SpecJApp), OpenJPA is extremely competitive.
>
> I have not closely examined your benchmark project, so I don't know how it
> compares to Trade and/or SpecJApp work loads. Any thoughts on this topic?
>
> One other thought... Just to prove that the enhancement processing is being
> done and you're not falling into the sub-classing support, could you run
> with the following property? This will cause your application to error-off
> if your Entities are not byte-code enhanced. We will not fall into the
> sub-classing support which greatly affects the performance.
>
> <property name="openjpa.RuntimeUnenhancedClasses"
> value="warn"/>
>
> It really seems that you are trying to do a fair comparison, and I greatly
> appreciate your efforts. The last time one of these comparisons was posted,
> the benchmark code and process was flawed. So, I am pleased to see the
> efforts associated with this exercise.
>
> Our performance lead is out having a baby, so we haven't been able to dig
> into your benchmark to the extent that we would like. If we can verify that
> the enhancement processing is happening, that would be good input. Thanks
> for your patience. What kind of timeframe are you under for posting this
> benchmark?
>
> Thanks,
> Kevin
>
> On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no> wrote:
>
>
>> Since we decided to go with vanilla installations of alle the frameworks we
>> have not added the connection pool feature to OpenJPA, until now.
>>
>> The results are sadly not that great. Yes, it's faster and it doesn't run
>> out of connections like before, BUT it's still 3, yes, -three- times slower
>> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
>> entities with many relations.
>>
>> Clearly this is not the kind of results I was hoping for and I'm quite
>> perplexed as to what to do.
>>
>> Shubbis
>>
>>
>> Nitish Kumar wrote:
>>
>>> Hi subbis,
>>> If I let the iteration loop over 5000, I get that exception, It
>>> seems (I am not sure) openjpa is creating a new connection and after a
>>> while mysql runs out of connection. I tried the same code and iteration
>>> loop with a connection pool and it works fine. That should get you
>>> moving as of now, till someone from Open JPA team looks into the issue.
>>>
>>> Thanks and Regards,
>>> Nitish Kumar
>>>
>>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>>
>>
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Kevin Sutter <kw...@gmail.com>.
Shubbis and Nitish,
Thanks for your efforts. So, to clarify -- all implementations are using
similar configurations (ie. connection pooling, caching, enhancement, etc)?
But, the OpenJPA performance is still 3 times slower than the competitors?
In all of the scenarios? Or, just with this ManyToMany scenario? I would
expect some overhead as compared to iBatis and/or straight JDBC, but OpenJPA
should be competitive (and beat) the Hibernates and EclipseLinks... Very
frustrating. When we do our comparisons with the industry benchmarks (Trade
and SpecJApp), OpenJPA is extremely competitive.
I have not closely examined your benchmark project, so I don't know how it
compares to Trade and/or SpecJApp work loads. Any thoughts on this topic?
One other thought... Just to prove that the enhancement processing is being
done and you're not falling into the sub-classing support, could you run
with the following property? This will cause your application to error-off
if your Entities are not byte-code enhanced. We will not fall into the
sub-classing support which greatly affects the performance.
<property name="openjpa.RuntimeUnenhancedClasses"
value="warn"/>
It really seems that you are trying to do a fair comparison, and I greatly
appreciate your efforts. The last time one of these comparisons was posted,
the benchmark code and process was flawed. So, I am pleased to see the
efforts associated with this exercise.
Our performance lead is out having a baby, so we haven't been able to dig
into your benchmark to the extent that we would like. If we can verify that
the enhancement processing is happening, that would be good input. Thanks
for your patience. What kind of timeframe are you under for posting this
benchmark?
Thanks,
Kevin
On Thu, Mar 19, 2009 at 9:05 AM, Shubbis <ma...@broadpark.no> wrote:
>
> Since we decided to go with vanilla installations of alle the frameworks we
> have not added the connection pool feature to OpenJPA, until now.
>
> The results are sadly not that great. Yes, it's faster and it doesn't run
> out of connections like before, BUT it's still 3, yes, -three- times slower
> than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
> entities with many relations.
>
> Clearly this is not the kind of results I was hoping for and I'm quite
> perplexed as to what to do.
>
> Shubbis
>
>
> Nitish Kumar wrote:
> >
> > Hi subbis,
> > If I let the iteration loop over 5000, I get that exception, It
> > seems (I am not sure) openjpa is creating a new connection and after a
> > while mysql runs out of connection. I tried the same code and iteration
> > loop with a connection pool and it works fine. That should get you
> > moving as of now, till someone from Open JPA team looks into the issue.
> >
> > Thanks and Regards,
> > Nitish Kumar
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
RE: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Since we decided to go with vanilla installations of alle the frameworks we
have not added the connection pool feature to OpenJPA, until now.
The results are sadly not that great. Yes, it's faster and it doesn't run
out of connections like before, BUT it's still 3, yes, -three- times slower
than Hibernate, EclipseLink, iBatis and regular JDBC when persisting
entities with many relations.
Clearly this is not the kind of results I was hoping for and I'm quite
perplexed as to what to do.
Shubbis
Nitish Kumar wrote:
>
> Hi subbis,
> If I let the iteration loop over 5000, I get that exception, It
> seems (I am not sure) openjpa is creating a new connection and after a
> while mysql runs out of connection. I tried the same code and iteration
> loop with a connection pool and it works fine. That should get you
> moving as of now, till someone from Open JPA team looks into the issue.
>
> Thanks and Regards,
> Nitish Kumar
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2503084.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
RE: Slow performance with OpenJPA when selecting from a ManyToMany relation.
Posted by Nitish Kumar <Ni...@proteans.com>.
Hi subbis,
If I let the iteration loop over 5000, I get that exception, It
seems (I am not sure) openjpa is creating a new connection and after a
while mysql runs out of connection. I tried the same code and iteration
loop with a connection pool and it works fine. That should get you
moving as of now, till someone from Open JPA team looks into the issue.
Thanks and Regards,
Nitish Kumar
-----Original Message-----
From: Shubbis [mailto:marius.jones@broadpark.no]
Sent: Thursday, March 19, 2009 1:50 PM
To: users@openjpa.apache.org
Subject: Re: Slow performance with OpenJPA when selecting from a
ManyToMany relation.
Hi, thanks for the suggestion, but we are aware of that, and we have
turned
it off on EclipseLink to even the playingfield.
Today we found a new problem with OpenJPA. When running the following
method
we get a similar type of performance hit and an Exception after the
first
run. Note: This exception is the same one we get when running the
ManyToMany
test in a loop.
The method:
public void insertDeliveryCompany(int iterations) throws
Exception{
log.setMethod(iterations);
for (int i = 0; i < 10; i++) {
// DeliveryCompany med contactinfo, adress,
areacode og country
IDeliveryCompanyDAO dcDao =
daoFactory.getDeliveryCompanyDAO();
DeliveryCompany deliveryCompany;
ArrayList<DeliveryCompany> deliveryCompanies =
new
ArrayList<DeliveryCompany>();
// Fyller DeliveryCompany listen
for(int interval = 0; interval < iterations;
interval++){
// Region
Region region = new Region();
region.setRegion("insertDeliveryCompanyRegion");
// Country
Country country = new Country();
country.setCountry("insertDeliveryCompanyCountry");
country.setRegion(region);
// AreaCode
AreaCode areaCode = new AreaCode();
areaCode.setArea("insertDeliveryCompanyAreaCode");
areaCode.setCountry(country);
// Address
Address address = new Address();
address.setAddress("insertDeliveryCompanyAddress");
address.setAreaCode(areaCode);
// ContactInfo
ContactInfo contactInfo = new
ContactInfo();
contactInfo.setAddress(address);
contactInfo.setEmail("insertDeliveryCompanyEmail");
contactInfo.setPhoneNr("insertDeliveryCompanyPhoneNr");
// Fyller DeliveryCompany listen
deliveryCompany = new DeliveryCompany();
deliveryCompany.setCompanyName("insertDeliveryCompany");
deliveryCompany.setContactInfo(contactInfo);
deliveryCompanies.add(deliveryCompany);
}
log.registerStart();
daoFactory.beginTransaction();
for (int j = 1; j <= iterations; j++) {
dcDao.save(deliveryCompanies.get(j-1));
log.registerIteration(j + 1);
}
daoFactory.commitTransaction();
// daoFactory.resetEntityManager();
log.registerEnd();
}
log.endMethod();
}
And the console dump:
94 OpenJPAPU INFO [main] openjpa.Runtime - Starting OpenJPA 1.2.0
172 OpenJPAPU INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.MySQLDictionary".
OPENJPA (insertDeliveryCompany): 43500
0 OpenJPAPU INFO [main] openjpa.Runtime - Starting OpenJPA 1.2.0
0 OpenJPAPU INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.MySQLDictionary".
<openjpa-1.2.0-r422266:683325 nonfatal general error>
org.apache.openjpa.persistence.PersistenceException: Communications link
failure
Last packet sent to the server was 0 ms ago.
at
org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.
java:4203)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:10
2)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88
)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64
)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager
.java:868)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getConnection(JDBCStoreM
anager.java:229)
at
org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:371)
at
org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:325)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getInitializeStateResult
(JDBCStoreManager.java:441)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStor
eManager.java:321)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreMana
ger.java:277)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingSt
oreManager.java:111)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.jav
a:57)
at
org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
at
org.apache.openjpa.kernel.BrokerImpl.isDetached(BrokerImpl.java:4286)
at
org.apache.openjpa.kernel.SingleFieldManager.persist(SingleFieldManager.
java:257)
at
org.apache.openjpa.kernel.StateManagerImpl.cascadePersist(StateManagerIm
pl.java:2893)
at
org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2457)
at
org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2280)
at
org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java
:1021)
at
org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerIm
pl.java:645)
at
project.ojpa.dao.DeliveryCompanyDAO.save(DeliveryCompanyDAO.java:55)
at
project.tests.InsertManager.insertDeliveryCompany(InsertManager.java:233
)
at project.client.AnalyticsClient.main(AnalyticsClient.java:67)
Caused by: com.mysql.jdbc.CommunicationsException: Communications link
failure
Last packet sent to the server was 0 ms ago.
at
com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1070
)
at
com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2120)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:723)
at
com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:298)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:28
2)
at
org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getConnection(Simp
leDriverDataSource.java:81)
at
org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getConnection(Simp
leDriverDataSource.java:76)
at
org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(Delegatin
gDataSource.java:113)
at
org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(Decoratin
gDataSource.java:93)
at
org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(Delegatin
gDataSource.java:113)
at
org.apache.openjpa.jdbc.schema.DataSourceFactory$DefaultsDataSource.getC
onnection(DataSourceFactory.java:305)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connectInternal(JDBCStor
eManager.java:879)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager
.java:864)
... 21 more
Caused by: com.mysql.jdbc.CommunicationsException: The driver was unable
to
create a connection due to an inability to establish the client portion
of a
socket.
This is usually caused by a limit on the number of sockets imposed by
the
operating system. This limit is usually configurable.
For Unix-based platforms, see the manual page for the 'ulimit' command.
Kernel or system reconfiguration may also be required.
For Windows-based platforms, see Microsoft Knowledge Base Article 196271
(Q196271).
at
com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1070
)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:335)
at
com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2043)
... 32 more
Caused by: java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at
com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:
253)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:284)
... 33 more
Kevin Sutter wrote:
>
> One other interesting bit of information... I just heard that
EclipseLink
> runs with a data cache enabled by default, while OpenJPA and Hibernate
do
> not. Although this setting may not get us completely out of this
> ManyToMany
> performance hole, it is something to be aware of as these performance
> benchmarks are done...
>
--
View this message in context:
http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a
-ManyToMany-relation.-tp2466994p2501684.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
-------------------------------------------------------------------------------------------------------------------------
"The information contained in this e-mail transmission is confidential and may be privileged. It is intended only for the
addressee(s) stated above. If you are not an addressee, any use, dissemination, distribution, publication, or copying of
the information contained in this e-mail is strictly prohibited. If you have received this e-mail in error, please
immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender and delete the e-mail from your system.
If you do not want to receive our emails please let us know so that we may delete you from our email list. Proteans
Software Solutions and its parent group ("CAMO Group") do not accept liability for damage caused by this email, and may
monitor email traffic."
-------------------------------------------------------------------------------------------------------------------------
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Hi, thanks for the suggestion, but we are aware of that, and we have turned
it off on EclipseLink to even the playingfield.
Today we found a new problem with OpenJPA. When running the following method
we get a similar type of performance hit and an Exception after the first
run. Note: This exception is the same one we get when running the ManyToMany
test in a loop.
The method:
public void insertDeliveryCompany(int iterations) throws Exception{
log.setMethod(iterations);
for (int i = 0; i < 10; i++) {
// DeliveryCompany med contactinfo, adress, areacode og country
IDeliveryCompanyDAO dcDao = daoFactory.getDeliveryCompanyDAO();
DeliveryCompany deliveryCompany;
ArrayList<DeliveryCompany> deliveryCompanies = new
ArrayList<DeliveryCompany>();
// Fyller DeliveryCompany listen
for(int interval = 0; interval < iterations; interval++){
// Region
Region region = new Region();
region.setRegion("insertDeliveryCompanyRegion");
// Country
Country country = new Country();
country.setCountry("insertDeliveryCompanyCountry");
country.setRegion(region);
// AreaCode
AreaCode areaCode = new AreaCode();
areaCode.setArea("insertDeliveryCompanyAreaCode");
areaCode.setCountry(country);
// Address
Address address = new Address();
address.setAddress("insertDeliveryCompanyAddress");
address.setAreaCode(areaCode);
// ContactInfo
ContactInfo contactInfo = new ContactInfo();
contactInfo.setAddress(address);
contactInfo.setEmail("insertDeliveryCompanyEmail");
contactInfo.setPhoneNr("insertDeliveryCompanyPhoneNr");
// Fyller DeliveryCompany listen
deliveryCompany = new DeliveryCompany();
deliveryCompany.setCompanyName("insertDeliveryCompany");
deliveryCompany.setContactInfo(contactInfo);
deliveryCompanies.add(deliveryCompany);
}
log.registerStart();
daoFactory.beginTransaction();
for (int j = 1; j <= iterations; j++) {
dcDao.save(deliveryCompanies.get(j-1));
log.registerIteration(j + 1);
}
daoFactory.commitTransaction();
// daoFactory.resetEntityManager();
log.registerEnd();
}
log.endMethod();
}
And the console dump:
94 OpenJPAPU INFO [main] openjpa.Runtime - Starting OpenJPA 1.2.0
172 OpenJPAPU INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.MySQLDictionary".
OPENJPA (insertDeliveryCompany): 43500
0 OpenJPAPU INFO [main] openjpa.Runtime - Starting OpenJPA 1.2.0
0 OpenJPAPU INFO [main] openjpa.jdbc.JDBC - Using dictionary class
"org.apache.openjpa.jdbc.sql.MySQLDictionary".
<openjpa-1.2.0-r422266:683325 nonfatal general error>
org.apache.openjpa.persistence.PersistenceException: Communications link
failure
Last packet sent to the server was 0 ms ago.
at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4238)
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4203)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:868)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getConnection(JDBCStoreManager.java:229)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:371)
at org.apache.openjpa.jdbc.sql.SelectImpl.execute(SelectImpl.java:325)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.getInitializeStateResult(JDBCStoreManager.java:441)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:321)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:277)
at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
at org.apache.openjpa.kernel.BrokerImpl.isDetached(BrokerImpl.java:4286)
at
org.apache.openjpa.kernel.SingleFieldManager.persist(SingleFieldManager.java:257)
at
org.apache.openjpa.kernel.StateManagerImpl.cascadePersist(StateManagerImpl.java:2893)
at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2457)
at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2280)
at
org.apache.openjpa.kernel.DelegatingBroker.persist(DelegatingBroker.java:1021)
at
org.apache.openjpa.persistence.EntityManagerImpl.persist(EntityManagerImpl.java:645)
at project.ojpa.dao.DeliveryCompanyDAO.save(DeliveryCompanyDAO.java:55)
at
project.tests.InsertManager.insertDeliveryCompany(InsertManager.java:233)
at project.client.AnalyticsClient.main(AnalyticsClient.java:67)
Caused by: com.mysql.jdbc.CommunicationsException: Communications link
failure
Last packet sent to the server was 0 ms ago.
at
com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1070)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2120)
at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:723)
at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:298)
at
com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:282)
at
org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getConnection(SimpleDriverDataSource.java:81)
at
org.apache.openjpa.jdbc.schema.SimpleDriverDataSource.getConnection(SimpleDriverDataSource.java:76)
at
org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:113)
at
org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:93)
at
org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:113)
at
org.apache.openjpa.jdbc.schema.DataSourceFactory$DefaultsDataSource.getConnection(DataSourceFactory.java:305)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connectInternal(JDBCStoreManager.java:879)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.connect(JDBCStoreManager.java:864)
... 21 more
Caused by: com.mysql.jdbc.CommunicationsException: The driver was unable to
create a connection due to an inability to establish the client portion of a
socket.
This is usually caused by a limit on the number of sockets imposed by the
operating system. This limit is usually configurable.
For Unix-based platforms, see the manual page for the 'ulimit' command.
Kernel or system reconfiguration may also be required.
For Windows-based platforms, see Microsoft Knowledge Base Article 196271
(Q196271).
at
com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1070)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:335)
at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2043)
... 32 more
Caused by: java.net.BindException: Address already in use: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at
com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:253)
at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:284)
... 33 more
Kevin Sutter wrote:
>
> One other interesting bit of information... I just heard that EclipseLink
> runs with a data cache enabled by default, while OpenJPA and Hibernate do
> not. Although this setting may not get us completely out of this
> ManyToMany
> performance hole, it is something to be aware of as these performance
> benchmarks are done...
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2501684.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Kevin Sutter <kw...@gmail.com>.
One other interesting bit of information... I just heard that EclipseLink
runs with a data cache enabled by default, while OpenJPA and Hibernate do
not. Although this setting may not get us completely out of this ManyToMany
performance hole, it is something to be aware of as these performance
benchmarks are done...
Kevin
On Wed, Mar 18, 2009 at 6:59 AM, Nitish Kumar <Ni...@proteans.com>wrote:
> Hi,
> My stats on this, I just ran it on Win XP (JRE 1.5.0_14) and
> local MySQL, took an average of 3.8 sec to complete 500 iterations.
> Removed the many to many association, doesn't affect the numbers much.
> Make the fetch as eager and it takes 4.2 sec.
>
> Something weird here, added the setting <property
> name="openjpa.jdbc.DBDictionary" value="JoinSyntax=traditional"/> and it
> goes up to 7.2 sec with eager and 4 sec with lazy.
>
> PS: I still could not make the enhancer work with ANT so I wrote a
> simple class
>
> public static void main(String[] args) {
> Collection listFiles = FileUtils.listFiles(new
> File("./src/model"),
> new String[] { "java" }, true);
> for (Object object : listFiles) {
> File file = (File) object;
> String[] args1 = new String[] { file.getPath()
> };
> PCEnhancer.main(args1);
> }
> }
>
> it has a dependency on commons-io but works great.
>
> Thanks and Regards,
> Nitish Kumar
>
> -----Original Message-----
> From: Shubbis [mailto:marius.jones@broadpark.no]
> Sent: Wednesday, March 18, 2009 12:01 AM
> To: users@openjpa.apache.org
> Subject: Re: Slow performance with OpenJPA when selecting from a
> ManyToMany relation.
>
>
> Ok, I still dont know what the problem is, but it seems like its not
> OpenJPA's fault (i think).
> I just took the whole project home with me, and installed it on my own
> laptop in a new workspace, and what do you know.. It took 2.3 sec.
> compared
> to the 12-15 sec.
>
> Now, I still don't know the root of the cause, since we have tried it on
> multiple computers at work, but at least this confirms that the project
> itself is working.
>
> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
> Nice
> work ;)
>
> Shubbis
>
> PS: adding the project if anyone wants to see. This is without all Ant
> and
> OpenJPA jar files as they were to big to upload here.
>
> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
> OpenJPASISTETEST.rar
>
>
> Pinaki Poddar wrote:
> >
> > Hi,
> >> Maybe someone could post an example of their build.xml file so that i
> >> could try it. See if maybe its my
> >> enhancing thats the problem.
> >
> > If you are an Eclipse IDE user, you can try a plugin [1] that keeps
> your
> > classes enhanced always. Or you may be better of with Ant builds as
> Mike
> > had provided.
> >
> > In either case, Enhancer displays log messages and running it twice
> > perhaps will confirm -- because second time it will say: 'class X is
> > already persistence-capable. Ignoring...' etc.
> >
> > [1] http://people.apache.org/~ppoddar/eclipse/<http://people.apache.org/%7Eppoddar/eclipse/>
> >
> >
>
>
>
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a
> -ManyToMany-relation.-tp2466994p2493009.html<http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a%0A-ManyToMany-relation.-tp2466994p2493009.html>
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
>
> -------------------------------------------------------------------------------------------------------------------------
> "The information contained in this e-mail transmission is confidential and
> may be privileged. It is intended only for the
> addressee(s) stated above. If you are not an addressee, any use,
> dissemination, distribution, publication, or copying of
> the information contained in this e-mail is strictly prohibited. If you
> have received this e-mail in error, please
> immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender
> and delete the e-mail from your system.
> If you do not want to receive our emails please let us know so that we may
> delete you from our email list. Proteans
> Software Solutions and its parent group ("CAMO Group") do not accept
> liability for damage caused by this email, and may
> monitor email traffic."
>
> -------------------------------------------------------------------------------------------------------------------------
>
>
RE: Slow performance with OpenJPA when selecting from a ManyToMany relation.
Posted by Nitish Kumar <Ni...@proteans.com>.
Hi,
My stats on this, I just ran it on Win XP (JRE 1.5.0_14) and
local MySQL, took an average of 3.8 sec to complete 500 iterations.
Removed the many to many association, doesn't affect the numbers much.
Make the fetch as eager and it takes 4.2 sec.
Something weird here, added the setting <property
name="openjpa.jdbc.DBDictionary" value="JoinSyntax=traditional"/> and it
goes up to 7.2 sec with eager and 4 sec with lazy.
PS: I still could not make the enhancer work with ANT so I wrote a
simple class
public static void main(String[] args) {
Collection listFiles = FileUtils.listFiles(new
File("./src/model"),
new String[] { "java" }, true);
for (Object object : listFiles) {
File file = (File) object;
String[] args1 = new String[] { file.getPath()
};
PCEnhancer.main(args1);
}
}
it has a dependency on commons-io but works great.
Thanks and Regards,
Nitish Kumar
-----Original Message-----
From: Shubbis [mailto:marius.jones@broadpark.no]
Sent: Wednesday, March 18, 2009 12:01 AM
To: users@openjpa.apache.org
Subject: Re: Slow performance with OpenJPA when selecting from a
ManyToMany relation.
Ok, I still dont know what the problem is, but it seems like its not
OpenJPA's fault (i think).
I just took the whole project home with me, and installed it on my own
laptop in a new workspace, and what do you know.. It took 2.3 sec.
compared
to the 12-15 sec.
Now, I still don't know the root of the cause, since we have tried it on
multiple computers at work, but at least this confirms that the project
itself is working.
Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
Nice
work ;)
Shubbis
PS: adding the project if anyone wants to see. This is without all Ant
and
OpenJPA jar files as they were to big to upload here.
http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
OpenJPASISTETEST.rar
Pinaki Poddar wrote:
>
> Hi,
>> Maybe someone could post an example of their build.xml file so that i
>> could try it. See if maybe its my
>> enhancing thats the problem.
>
> If you are an Eclipse IDE user, you can try a plugin [1] that keeps
your
> classes enhanced always. Or you may be better of with Ant builds as
Mike
> had provided.
>
> In either case, Enhancer displays log messages and running it twice
> perhaps will confirm -- because second time it will say: 'class X is
> already persistence-capable. Ignoring...' etc.
>
> [1] http://people.apache.org/~ppoddar/eclipse/
>
>
--
View this message in context:
http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a
-ManyToMany-relation.-tp2466994p2493009.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
-------------------------------------------------------------------------------------------------------------------------
"The information contained in this e-mail transmission is confidential and may be privileged. It is intended only for the
addressee(s) stated above. If you are not an addressee, any use, dissemination, distribution, publication, or copying of
the information contained in this e-mail is strictly prohibited. If you have received this e-mail in error, please
immediately notify us by telephone (+91 80 6618 6555), or e-mail the sender and delete the e-mail from your system.
If you do not want to receive our emails please let us know so that we may delete you from our email list. Proteans
Software Solutions and its parent group ("CAMO Group") do not accept liability for damage caused by this email, and may
monitor email traffic."
-------------------------------------------------------------------------------------------------------------------------
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
And a link to the complete project, with all jar files etc in the lib folder.
http://files.sharetoad.com/?id=f89de9caa6 OpenJPA project
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2496066.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Yes, we checked the SQL and I have also tried with different joinsyntax.. no
luck :/
Thanks though.
Shubbis
Georgi Naplatanov wrote:
>
> Hello Shubbis.
>
> Did you check generated SQL ?
>
> OpenJPA has property about how to perform joins.
>
> My be with traditional join syntax performance will be better.
>
> <property name="openjpa.jdbc.DBDictionary"
> value="JoinSyntax=traditional"/>
>
> Best regards
> Georgi
>
> Shubbis wrote:
>> Todays update, for those who are interested. ;)
>>
>> I've uninstalled all JRE, JDK, SDK etc all java dirs have been deleted
>> and
>> I've reinstalled everything (related to java) and downloaded Eclipse
>> Ganymede, I installed the latest nightly build of OpenJPA and made a
>> fresh
>> new project, I even copied the project from home and imported it, still
>> no
>> luck with the resulting time.
>>
>> Now, here's the kicker. I exported to a runnable jar file and ran it on a
>> Debian linux server, the same one that runs our MySQL server, and it took
>> 5~
>> sec. to complete 500 iterations. So half the time, but still not close to
>> good enough..
>>
>> I just don't get it!
>>
>> Anything..?
>>
>> Shubbis
>>
>>
>> Paul Copeland wrote:
>>> What is different abut your laptop at home vs. multiple computers at
>>> work? Are they all connected to the same network?
>>>
>>> On 3/17/2009 11:30 AM, Shubbis wrote:
>>>> Ok, I still dont know what the problem is, but it seems like its not
>>>> OpenJPA's fault (i think).
>>>> I just took the whole project home with me, and installed it on my own
>>>> laptop in a new workspace, and what do you know.. It took 2.3 sec.
>>>> compared
>>>> to the 12-15 sec.
>>>>
>>>> Now, I still don't know the root of the cause, since we have tried it
>>>> on
>>>> multiple computers at work, but at least this confirms that the project
>>>> itself is working.
>>>>
>>>> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
>>>> Nice
>>>> work ;)
>>>>
>>>> Shubbis
>>>>
>>>> PS: adding the project if anyone wants to see. This is without all Ant
>>>> and
>>>> OpenJPA jar files as they were to big to upload here.
>>>>
>>>> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
>>>> OpenJPASISTETEST.rar
>>>>
>>>>
>>>> Pinaki Poddar wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>> Maybe someone could post an example of their build.xml file so that i
>>>>>> could try it. See if maybe its my
>>>>>> enhancing thats the problem.
>>>>>>
>>>>> If you are an Eclipse IDE user, you can try a plugin [1] that keeps
>>>>> your
>>>>> classes enhanced always. Or you may be better of with Ant builds as
>>>>> Mike
>>>>> had provided.
>>>>>
>>>>> In either case, Enhancer displays log messages and running it twice
>>>>> perhaps will confirm -- because second time it will say: 'class X is
>>>>> already persistence-capable. Ignoring...' etc.
>>>>>
>>>>> [1] http://people.apache.org/~ppoddar/eclipse/
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2501693.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Georgi Naplatanov <go...@oles.biz>.
Hello Shubbis.
Did you check generated SQL ?
OpenJPA has property about how to perform joins.
My be with traditional join syntax performance will be better.
<property name="openjpa.jdbc.DBDictionary" value="JoinSyntax=traditional"/>
Best regards
Georgi
Shubbis wrote:
> Todays update, for those who are interested. ;)
>
> I've uninstalled all JRE, JDK, SDK etc all java dirs have been deleted and
> I've reinstalled everything (related to java) and downloaded Eclipse
> Ganymede, I installed the latest nightly build of OpenJPA and made a fresh
> new project, I even copied the project from home and imported it, still no
> luck with the resulting time.
>
> Now, here's the kicker. I exported to a runnable jar file and ran it on a
> Debian linux server, the same one that runs our MySQL server, and it took 5~
> sec. to complete 500 iterations. So half the time, but still not close to
> good enough..
>
> I just don't get it!
>
> Anything..?
>
> Shubbis
>
>
> Paul Copeland wrote:
>> What is different abut your laptop at home vs. multiple computers at
>> work? Are they all connected to the same network?
>>
>> On 3/17/2009 11:30 AM, Shubbis wrote:
>>> Ok, I still dont know what the problem is, but it seems like its not
>>> OpenJPA's fault (i think).
>>> I just took the whole project home with me, and installed it on my own
>>> laptop in a new workspace, and what do you know.. It took 2.3 sec.
>>> compared
>>> to the 12-15 sec.
>>>
>>> Now, I still don't know the root of the cause, since we have tried it on
>>> multiple computers at work, but at least this confirms that the project
>>> itself is working.
>>>
>>> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
>>> Nice
>>> work ;)
>>>
>>> Shubbis
>>>
>>> PS: adding the project if anyone wants to see. This is without all Ant
>>> and
>>> OpenJPA jar files as they were to big to upload here.
>>>
>>> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
>>> OpenJPASISTETEST.rar
>>>
>>>
>>> Pinaki Poddar wrote:
>>>
>>>> Hi,
>>>>
>>>>> Maybe someone could post an example of their build.xml file so that i
>>>>> could try it. See if maybe its my
>>>>> enhancing thats the problem.
>>>>>
>>>> If you are an Eclipse IDE user, you can try a plugin [1] that keeps
>>>> your
>>>> classes enhanced always. Or you may be better of with Ant builds as Mike
>>>> had provided.
>>>>
>>>> In either case, Enhancer displays log messages and running it twice
>>>> perhaps will confirm -- because second time it will say: 'class X is
>>>> already persistence-capable. Ignoring...' etc.
>>>>
>>>> [1] http://people.apache.org/~ppoddar/eclipse/
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Todays update, for those who are interested. ;)
I've uninstalled all JRE, JDK, SDK etc all java dirs have been deleted and
I've reinstalled everything (related to java) and downloaded Eclipse
Ganymede, I installed the latest nightly build of OpenJPA and made a fresh
new project, I even copied the project from home and imported it, still no
luck with the resulting time.
Now, here's the kicker. I exported to a runnable jar file and ran it on a
Debian linux server, the same one that runs our MySQL server, and it took 5~
sec. to complete 500 iterations. So half the time, but still not close to
good enough..
I just don't get it!
Anything..?
Shubbis
Paul Copeland wrote:
>
> What is different abut your laptop at home vs. multiple computers at
> work? Are they all connected to the same network?
>
> On 3/17/2009 11:30 AM, Shubbis wrote:
>> Ok, I still dont know what the problem is, but it seems like its not
>> OpenJPA's fault (i think).
>> I just took the whole project home with me, and installed it on my own
>> laptop in a new workspace, and what do you know.. It took 2.3 sec.
>> compared
>> to the 12-15 sec.
>>
>> Now, I still don't know the root of the cause, since we have tried it on
>> multiple computers at work, but at least this confirms that the project
>> itself is working.
>>
>> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
>> Nice
>> work ;)
>>
>> Shubbis
>>
>> PS: adding the project if anyone wants to see. This is without all Ant
>> and
>> OpenJPA jar files as they were to big to upload here.
>>
>> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
>> OpenJPASISTETEST.rar
>>
>>
>> Pinaki Poddar wrote:
>>
>>> Hi,
>>>
>>>> Maybe someone could post an example of their build.xml file so that i
>>>> could try it. See if maybe its my
>>>> enhancing thats the problem.
>>>>
>>> If you are an Eclipse IDE user, you can try a plugin [1] that keeps
>>> your
>>> classes enhanced always. Or you may be better of with Ant builds as Mike
>>> had provided.
>>>
>>> In either case, Enhancer displays log messages and running it twice
>>> perhaps will confirm -- because second time it will say: 'class X is
>>> already persistence-capable. Ignoring...' etc.
>>>
>>> [1] http://people.apache.org/~ppoddar/eclipse/
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2496032.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
That's what I'm going to try and figure out tomorrow when I get there. Going
to take this laptop with me and see if I can figure it out. They are not on
the same network, though that shouldn't matter as I have used a local MySQL
install on all computers.
Will of course update when if/when I find anything.
Shubbis
Paul Copeland wrote:
>
> What is different abut your laptop at home vs. multiple computers at
> work? Are they all connected to the same network?
>
> On 3/17/2009 11:30 AM, Shubbis wrote:
>> Ok, I still dont know what the problem is, but it seems like its not
>> OpenJPA's fault (i think).
>> I just took the whole project home with me, and installed it on my own
>> laptop in a new workspace, and what do you know.. It took 2.3 sec.
>> compared
>> to the 12-15 sec.
>>
>> Now, I still don't know the root of the cause, since we have tried it on
>> multiple computers at work, but at least this confirms that the project
>> itself is working.
>>
>> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI.
>> Nice
>> work ;)
>>
>> Shubbis
>>
>> PS: adding the project if anyone wants to see. This is without all Ant
>> and
>> OpenJPA jar files as they were to big to upload here.
>>
>> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar
>> OpenJPASISTETEST.rar
>>
>>
>> Pinaki Poddar wrote:
>>
>>> Hi,
>>>
>>>> Maybe someone could post an example of their build.xml file so that i
>>>> could try it. See if maybe its my
>>>> enhancing thats the problem.
>>>>
>>> If you are an Eclipse IDE user, you can try a plugin [1] that keeps
>>> your
>>> classes enhanced always. Or you may be better of with Ant builds as Mike
>>> had provided.
>>>
>>> In either case, Enhancer displays log messages and running it twice
>>> perhaps will confirm -- because second time it will say: 'class X is
>>> already persistence-capable. Ignoring...' etc.
>>>
>>> [1] http://people.apache.org/~ppoddar/eclipse/
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2493293.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Paul Copeland <te...@jotobjects.com>.
What is different abut your laptop at home vs. multiple computers at
work? Are they all connected to the same network?
On 3/17/2009 11:30 AM, Shubbis wrote:
> Ok, I still dont know what the problem is, but it seems like its not
> OpenJPA's fault (i think).
> I just took the whole project home with me, and installed it on my own
> laptop in a new workspace, and what do you know.. It took 2.3 sec. compared
> to the 12-15 sec.
>
> Now, I still don't know the root of the cause, since we have tried it on
> multiple computers at work, but at least this confirms that the project
> itself is working.
>
> Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI. Nice
> work ;)
>
> Shubbis
>
> PS: adding the project if anyone wants to see. This is without all Ant and
> OpenJPA jar files as they were to big to upload here.
>
> http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar OpenJPASISTETEST.rar
>
>
> Pinaki Poddar wrote:
>
>> Hi,
>>
>>> Maybe someone could post an example of their build.xml file so that i
>>> could try it. See if maybe its my
>>> enhancing thats the problem.
>>>
>> If you are an Eclipse IDE user, you can try a plugin [1] that keeps your
>> classes enhanced always. Or you may be better of with Ant builds as Mike
>> had provided.
>>
>> In either case, Enhancer displays log messages and running it twice
>> perhaps will confirm -- because second time it will say: 'class X is
>> already persistence-capable. Ignoring...' etc.
>>
>> [1] http://people.apache.org/~ppoddar/eclipse/
>>
>>
>>
>
>
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Ok, I still dont know what the problem is, but it seems like its not
OpenJPA's fault (i think).
I just took the whole project home with me, and installed it on my own
laptop in a new workspace, and what do you know.. It took 2.3 sec. compared
to the 12-15 sec.
Now, I still don't know the root of the cause, since we have tried it on
multiple computers at work, but at least this confirms that the project
itself is working.
Btw Pinaki, your plugin works perfect with MyEclipse 7.1.1 aswell. FYI. Nice
work ;)
Shubbis
PS: adding the project if anyone wants to see. This is without all Ant and
OpenJPA jar files as they were to big to upload here.
http://n2.nabble.com/file/n2493009/OpenJPASISTETEST.rar OpenJPASISTETEST.rar
Pinaki Poddar wrote:
>
> Hi,
>> Maybe someone could post an example of their build.xml file so that i
>> could try it. See if maybe its my
>> enhancing thats the problem.
>
> If you are an Eclipse IDE user, you can try a plugin [1] that keeps your
> classes enhanced always. Or you may be better of with Ant builds as Mike
> had provided.
>
> In either case, Enhancer displays log messages and running it twice
> perhaps will confirm -- because second time it will say: 'class X is
> already persistence-capable. Ignoring...' etc.
>
> [1] http://people.apache.org/~ppoddar/eclipse/
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2493009.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Pinaki Poddar <pp...@apache.org>.
Hi,
> Maybe someone could post an example of their build.xml file so that i
> could try it. See if maybe its my
> enhancing thats the problem.
If you are an Eclipse IDE user, you can try a plugin [1] that keeps your
classes enhanced always. Or you may be better of with Ant builds as Mike had
provided.
In either case, Enhancer displays log messages and running it twice
perhaps will confirm -- because second time it will say: 'class X is already
persistence-capable. Ignoring...' etc.
[1] http://people.apache.org/~ppoddar/eclipse/
Shubbis wrote:
>
>
>
> Pinaki Poddar wrote:
>>
>> I do not find anything obvious in the tests that can cause the slowdown.
>> Now the usual suspect: Have you enhanced Storeage/WeraHouse classes at
>> build-time?
>>
>>
>
>
> Shubbis
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2492297.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Rick Curtis <cu...@gmail.com>.
Would it be possible to have you zip up your entire directory structure and
upload that? Make sure that everything is compiled and enhanced... hopefully
that will shed some more light on what is going on.
-Rick
Shubbis wrote:
>
>
>
> Pinaki Poddar wrote:
>>
>> I do not find anything obvious in the tests that can cause the slowdown.
>> Now the usual suspect: Have you enhanced Storeage/WeraHouse classes at
>> build-time?
>>
>>
>
> Maybe someone could post an example of their build.xml file so that i
> could try it. See if maybe its my enhancing thats the problem.
>
> Shubbis
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2492327.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Michael Dick <mi...@gmail.com>.
A slightly overcomplicated example is in the OpenJPA source code. It a bit
kludgy since it's invoked during a maven build and we don't want it to run
if we aren't going to run the tests in maven..
You can see the file in fisheye at [1] .
The relevant portion of the file is here (I've removed some of the optional
stuff) :
<!-- =================================
target: enhance.all.entities
================================= -->
<target name="enhance.all.entities"
description="--> enhance the test entities"
unless="maven.test.skip.istrue">
<echo> running enhancer</echo>
<path id="cp">
<!-- make sure OpenJPA is on the classpath -->
<path refid="maven.test.classpath" />
</path>
<taskdef name="openjpac"
classname="org.apache.openjpa.ant.PCEnhancerTask">
<classpath refid="cp" />
</taskdef>
<fileset id="enhance.path.ref"
dir="${project.build.testOutputDirectory}">
<include name="**/*.class" />
<!-- optionally include or exclude more classes -->
</fileset>
<openjpac>
<classpath refid="cp" />
<fileset refid="enhance.path.ref" />
<config log="DefaultLevel=${openjpa.loglevel}" />
</openjpac>
</target>
[1]
http://fisheye6.atlassian.com/browse/~raw,r=697955/openjpa/trunk/openjpa-persistence-jdbc/src/main/ant/enhancer.xml
Hope this helps,
-mike
On Tue, Mar 17, 2009 at 9:27 AM, Shubbis <ma...@broadpark.no> wrote:
>
>
>
> Pinaki Poddar wrote:
> >
> > I do not find anything obvious in the tests that can cause the slowdown.
> > Now the usual suspect: Have you enhanced Storeage/WeraHouse classes at
> > build-time?
> >
> >
>
> Maybe someone could post an example of their build.xml file so that i could
> try it. See if maybe its my enhancing thats the problem.
>
> Shubbis
> --
> View this message in context:
> http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2491667.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Pinaki Poddar wrote:
>
> I do not find anything obvious in the tests that can cause the slowdown.
> Now the usual suspect: Have you enhanced Storeage/WeraHouse classes at
> build-time?
>
>
Maybe someone could post an example of their build.xml file so that i could
try it. See if maybe its my enhancing thats the problem.
Shubbis
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2491667.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Pinaki Poddar <pp...@apache.org>.
I do not find anything obvious in the tests that can cause the slowdown.
Now the usual suspect: Have you enhanced Storeage/WeraHouse classes at
build-time?
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2490519.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
And my persistence.xml
<persistence-unit name="OpenJPAPU" transaction-type="RESOURCE_LOCAL">
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
<class>test.model2.Wearhouse</class>
<class>test.model2.Storagecategory</class>
<properties>
<property name = "openjpa.ConnectionDriverName" value =
"com.mysql.jdbc.Driver"/>
<property name = "openjpa.ConnectionURL" value =
"jdbc:mysql://localhost:3306/openjpamanytomany"/>
<property name = "openjpa.ConnectionUserName" value = "root"/>
<property name = "openjpa.ConnectionPassword" value = "root"/>
<property name = "openjpa.jdbc.SynchronizeMappings" value =
"buildSchema(ForeignKeys=true)"/>
</properties>
</persistence-unit>
Shubbis
Shubbis wrote:
>
> Hi again,
>
> Thanks for your patience and I am sorry for the late reply, but we are
> only stationed at the offices three days a week.
>
> I must admit i don't understand what you mean by test harness. If you
> could explain i will gladly post it.
>
> In the meantime I have created a new project and added OpenJPA
> capabilities to this one in hopes of discovering what the problem is, but
> alas I did not.
> My new project is of a much simpler setup, it consists of the following
> files.
>
> Main class for running simple test:
> public static void main(String[] args) throws Exception {
> EntityManagerFactory factory =
> Persistence.createEntityManagerFactory("OpenJPAPU",
> System.getProperties());
> EntityManager em = factory.createEntityManager();
> OpenJPAEntityManager o = OpenJPAPersistence.cast(em);
>
> WearhouseDAO wd = new WearhouseDAO();
> long starttid = System.currentTimeMillis();
> for(int i = 1; i <= 500; i++){
> Wearhouse w = wd.findById(o, i);
> // System.out.println(w.getWearhouseName());
> }
> System.out.println(System.currentTimeMillis() - starttid);
> }
>
>
> Wearhouse Entity class (same as before)
> WearhouseDAO class using the following method:
> public Wearhouse findById(OpenJPAEntityManager o, Integer id) {
> try {
> Wearhouse instance = o.find(Wearhouse.class, id);
> return instance;
> } catch (RuntimeException re) {
> throw re;
> }
> }
>
>
> Storagecategory Entity class (same as before)
> StoragecategoryDAO class using the following method:
> public Storagecategory findById(OpenJPAEntityManager o, Integer id) {
> try {
> Storagecategory instance = o.find(Storagecategory.class, id);
> return instance;
> } catch (RuntimeException re) {
> throw re;
> }
> }
>
> The database is still MySQL and this time I've let OpenJPA build the
> schema.
>
> No difference in the resulting time..
>
> Thanks for reading,
>
> Shub
>
>
> Pinaki Poddar wrote:
>>
>> Hi,
>> I ran the Wearhouse-StorageCategory model you have posted (thank you
>> for a clean test). Against 500 categories and 200 wearhouses and a
>> cardinality of 10 categories per wearhouse. The domain classes were
>> enhanced at build-time. The database is MySQL and the tests ran in my
>> pedestrian laptop. Here are the results for finding Wearhouses 500 times
>> in a loop.
>>
>> Without connection pool : 2360 ms.
>> With connection pool : 734ms
>>
>> Given these numbers are quite in contrast with your observations, I will
>> request you to post the test harness you used to measure the number, so
>> that we can investigate further.
>>
>> Few comments:
>> 1. If performance is higher priority than ordering, consider using
>> Set<> instead of List<>
>> 2. Consider using a connection pool, if possible [1]
>>
>> [1]
>> http://openjpa.apache.org/faq.html#FAQ-HowdoIenableconnectionpoolinginOpenJPA%253F
>>
>> Regards --
>>
>>
>> PS: "Aristotle maintained that women have fewer teeth than men; although
>> he was twice married, it never occurred to him to verify this statement
>> by examining his wives' mouths." --
>> The Impact of Science on Society, 1952 - Bertrand Russell
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2490426.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Shubbis <ma...@broadpark.no>.
Hi again,
Thanks for your patience and I am sorry for the late reply, but we are only
stationed at the offices three days a week.
I must admit i don't understand what you mean by test harness. If you could
explain i will gladly post it.
In the meantime I have created a new project and added OpenJPA capabilities
to this one in hopes of discovering what the problem is, but alas I did not.
My new project is of a much simpler setup, it consists of the following
files.
Main class for running simple test:
public static void main(String[] args) throws Exception {
EntityManagerFactory factory =
Persistence.createEntityManagerFactory("OpenJPAPU", System.getProperties());
EntityManager em = factory.createEntityManager();
OpenJPAEntityManager o = OpenJPAPersistence.cast(em);
WearhouseDAO wd = new WearhouseDAO();
long starttid = System.currentTimeMillis();
for(int i = 1; i <= 500; i++){
Wearhouse w = wd.findById(o, i);
// System.out.println(w.getWearhouseName());
}
System.out.println(System.currentTimeMillis() - starttid);
}
Wearhouse Entity class (same as before)
WearhouseDAO class using the following method:
public Wearhouse findById(OpenJPAEntityManager o, Integer id) {
try {
Wearhouse instance = o.find(Wearhouse.class, id);
return instance;
} catch (RuntimeException re) {
throw re;
}
}
Storagecategory Entity class (same as before)
StoragecategoryDAO class using the following method:
public Storagecategory findById(OpenJPAEntityManager o, Integer id) {
try {
Storagecategory instance = o.find(Storagecategory.class, id);
return instance;
} catch (RuntimeException re) {
throw re;
}
}
The database is still MySQL and this time I've let OpenJPA build the schema.
No difference in the resulting time..
Thanks for reading,
Shub
Pinaki Poddar wrote:
>
> Hi,
> I ran the Wearhouse-StorageCategory model you have posted (thank you for
> a clean test). Against 500 categories and 200 wearhouses and a cardinality
> of 10 categories per wearhouse. The domain classes were enhanced at
> build-time. The database is MySQL and the tests ran in my pedestrian
> laptop. Here are the results for finding Wearhouses 500 times in a loop.
>
> Without connection pool : 2360 ms.
> With connection pool : 734ms
>
> Given these numbers are quite in contrast with your observations, I will
> request you to post the test harness you used to measure the number, so
> that we can investigate further.
>
> Few comments:
> 1. If performance is higher priority than ordering, consider using Set<>
> instead of List<>
> 2. Consider using a connection pool, if possible [1]
>
> [1]
> http://openjpa.apache.org/faq.html#FAQ-HowdoIenableconnectionpoolinginOpenJPA%253F
>
> Regards --
>
>
> PS: "Aristotle maintained that women have fewer teeth than men; although
> he was twice married, it never occurred to him to verify this statement by
> examining his wives' mouths." --
> The Impact of Science on Society, 1952 - Bertrand Russell
>
>
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2490419.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Slow performance with OpenJPA when selecting from a ManyToMany
relation.
Posted by Pinaki Poddar <pp...@apache.org>.
Hi,
I ran the Wearhouse-StorageCategory model you have posted (thank you for a
clean test). Against 500 categories and 200 wearhouses and a cardinality of
10 categories per wearhouse. The domain classes were enhanced at build-time.
The database is MySQL and the tests ran in my pedestrian laptop. Here are
the results for finding Wearhouses 500 times in a loop.
Without connection pool : 2360 ms.
With connection pool : 734ms
Given these numbers are quite in contrast with your observations, I will
request you to post the test harness you used to measure the number, so that
we can investigate further.
Few comments:
1. If performance is higher priority than ordering, consider using Set<>
instead of List<>
2. Consider using a connection pool, if possible [1]
[1]
http://openjpa.apache.org/faq.html#FAQ-HowdoIenableconnectionpoolinginOpenJPA%253F
Regards --
PS: "Aristotle maintained that women have fewer teeth than men; although he
was twice married, it never occurred to him to verify this statement by
examining his wives' mouths." --
The Impact of Science on Society, 1952 - Bertrand Russell
--
View this message in context: http://n2.nabble.com/Slow-performance-with-OpenJPA-when-selecting-from-a-ManyToMany-relation.-tp2466994p2470215.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.