You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Heather Sterling <hs...@us.ibm.com> on 2009/05/11 21:40:12 UTC
correct way to load persistent metadata at startup
I am attempting to load all the persistent class metadata eagerly. I
realize this isn't great performance-wise, but I need to do it for the
time-being. I had wanted to call:
ClassMetaData[] classMetaDatas =
conf.getMetaDataRepositoryInstance().getMetaDatas();
but realized the data was loaded lazily when nothing came back. I switched
to using:);
Collection c = conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
true, null);
which returned the classes to me, but getMetaDatas() still returned
nothing. Finally, I resorted to iterating through the class names, which
seemed to work.
Set names = conf.getMetaDataRepositoryInstance
().getPersistentTypeNames(false, null);
if (names != null) {
for (Iterator it = names.iterator(); it.hasNext();) {
String persistentClassname = (String)it.next();
System.out.println("Pre-loading metadata for: " +
persistentClassname);
try {
ClassMetaData cc = conf.getMetaDataRepositoryInstance
().getMetaData(Class.forName(persistentClassname), null, true);
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
I found a link regarding a potential openjpa property called
openjpa.InitializeEagerly (
https://issues.apache.org/jira/browse/OPENJPA-620) but it was never checked
into a release.
Given all these options, what is the correct way to load the metadata on
startup?
Heather Sterling
Systems Management Development
Phone: 919-254-7163 T/L: 444-7163
Cell: 919-423-3143
Email: hsterl@us.ibm.com
Re: correct way to load persistent metadata at startup
Posted by Jeremy Bauer <te...@gmail.com>.
Heather,
Have you looked into creating a custom sequence generator[1]? Within the
generator, the persistent class and/or fields could be interrogated for
annotations and you could generate a value based on them. This is more of a
runtime vs. init-time solution, though.
Here's an example:
package generator;
import java.lang.reflect.AccessibleObject;
import org.apache.openjpa.jdbc.conf.JDBCConfiguration;
import org.apache.openjpa.jdbc.kernel.JDBCStore;
import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.meta.FieldMetaData;
public class MyGenerator extends
org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq
{
@Override
public JDBCConfiguration getConfiguration() {
return null;
}
@Override
protected Object nextInternal(JDBCStore arg0, ClassMapping arg1)
throws Exception {
FieldMetaData fmd = arg1.getFieldMapping("someField");
AccessibleObject fld = (AccessibleObject)fmd.getBackingMember();
MyAnnotation anno =
(MyAnnotation)fld.getAnnotation(MyAnnotation.class);
// Return the value of the annotation. This will get persisted in
the DB column.
return anno.value();
}
}
@Entity
@SequenceGenerator(name="myGenerator",
sequenceName="generator.MyGenerator()")
public class GenValue {
@MyAnnotation("FieldValue")
@GeneratedValue(generator="myGenerator",
strategy=GenerationType.SEQUENCE)
public String someField;
...
}
[1]
http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_sequence.html
-Jeremy
On Fri, May 15, 2009 at 2:06 PM, Kevin Sutter <kw...@gmail.com> wrote:
> Hi Heather,
> Interesting use of the OpenJPA metadata processing. Just from your brief
> description, I would be careful on depending on an implementation versus
> defined interfaces. Even if we could get this initialization done earlier
> for you, unless there was some defined mechanism to force this (ie. the
> openjpa.InitializeEagerly property), I wouldn't count on it. In this
> particular case, the metadata repository is meant for OpenJPA processing.
>
> I know with OpenJPA the lines may not be crystal clear between public
> API's,
> provider SPI's, or internal classes. Of course, since this is an
> open-source project, you are welcome to peruse the complete contents of the
> code base and see if a solution is doable or not. I would just be careful
> on being too dependent on a specific implementation.
>
> Kevin
>
> On Fri, May 15, 2009 at 9:30 AM, Heather Sterling <hs...@us.ibm.com>
> wrote:
>
> > Thanks Kevin.
> >
> > Our scenario is that we have added product-specific annotations to the
> > persistent classes. In particular, we have some annotations that we need
> in
> > our perPersist entity listener to generate unique identifiers before the
> > object is persisted. We're currently initializing all of the metadata at
> the
> > beginning. We essentially iterate through the persistent classes and
> create
> > maps that hold this extra information. I guess it's possible for us to
> > lazily load this data in the entity listener if it hasn't been loaded for
> a
> > particular class. I also looked to see if there was another hook we could
> > potentially use, but didn't see any that seemed to fit the problem.
> >
> >
> > Heather Sterling
> > Systems Management Development
> > Phone: 919-254-7163 T/L: 444-7163
> > Cell: 919-423-3143
> > Email: hsterl@us.ibm.com
> >
> >
> > [image: Inactive hide details for Kevin Sutter ---05/12/2009 12:53:30
> > PM---Heather,]
> > Kevin Sutter ---05/12/2009 12:53:30 PM---Heather,
> >
> >
> >
> >
> > *Kevin Sutter <kw...@gmail.com>*
> >
> > 05/12/2009 12:48 PM
> > Please respond to users
> >
> >
> >
> > To: users@openjpa.apache.org
> > cc:
> > Subject: Re: correct way to load persistent metadata at startup
> >
> >
> > Heather,
> > Good question... :-) This topic has come up recently due to some
> > potential
> > locking issues (serialized access) when reading the metadata repository
> in
> > a
> > multi-threaded environment. At this point, there is not a clear cut
> answer
> > for forcing the initialization of the metadata repository. The code for
> > the
> > new openjpa.InitializeEagerly property was committed to trunk last August
> > (after the 1.2.0 release was created), but we've since determined that it
> > may not be complete for all cases. You are welcome to try it out from
> > either the 1.3.x or trunk branches and see if it helps in your particular
> > situation.
> >
> > Let us know what you find out. Also, can you explain your need for
> getting
> > this data eagerly vs letting the lazy loading process play out? Thanks!
> >
> > Kevin
> >
> >
> >
> > On Mon, May 11, 2009 at 2:40 PM, Heather Sterling <hs...@us.ibm.com>
> > wrote:
> >
> > >
> > >
> > > I am attempting to load all the persistent class metadata eagerly. I
> > > realize this isn't great performance-wise, but I need to do it for the
> > > time-being. I had wanted to call:
> > >
> > > ClassMetaData[] classMetaDatas =
> > > conf.getMetaDataRepositoryInstance().getMetaDatas();
> > >
> > > but realized the data was loaded lazily when nothing came back. I
> > switched
> > > to using:);
> > >
> > > Collection c =
> conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
> > > true, null);
> > >
> > > which returned the classes to me, but getMetaDatas() still returned
> > > nothing. Finally, I resorted to iterating through the class names,
> which
> > > seemed to work.
> > >
> > > Set names = conf.getMetaDataRepositoryInstance
> > > ().getPersistentTypeNames(false, null);
> > > if (names != null) {
> > > for (Iterator it = names.iterator(); it.hasNext();) {
> > > String persistentClassname = (String)it.next();
> > > System.out.println("Pre-loading metadata for: " +
> > > persistentClassname);
> > > try {
> > > ClassMetaData cc =
> conf.getMetaDataRepositoryInstance
> > > ().getMetaData(Class.forName(persistentClassname), null, true);
> > > } catch (ClassNotFoundException e) {
> > > // TODO Auto-generated catch block
> > > e.printStackTrace();
> > > }
> > >
> > > }
> > > }
> > >
> > > I found a link regarding a potential openjpa property called
> > > openjpa.InitializeEagerly (
> > > https://issues.apache.org/jira/browse/OPENJPA-620) but it was never
> > > checked
> > > into a release.
> > >
> > > Given all these options, what is the correct way to load the metadata
> on
> > > startup?
> > >
> > >
> > > Heather Sterling
> > > Systems Management Development
> > > Phone: 919-254-7163 T/L: 444-7163
> > > Cell: 919-423-3143
> > > Email: hsterl@us.ibm.com
> >
>
Re: correct way to load persistent metadata at startup
Posted by Pinaki Poddar <pp...@apache.org>.
Hi,
> I am attempting to load all the persistent class metadata eagerly.
OpenJPA provides several ways to load persistent metadata eagerly. The
suggested approaches assume that META-INF/persistence.xml has listed the
persistent classes.
1. <property name="openjpa.InitializeEagerly" value="true"/> is arguably the
most straightforward approach, notwithstanding some comments on this thread
about this option that had stated otherwise.
2. Create a dummy EntityManager with
EntityManagerFactory.createEntityManager(). Metadata initialization will
kick in that way too.
Kevin Sutter wrote:
>
> Hi Heather,
> Interesting use of the OpenJPA metadata processing. Just from your brief
> description, I would be careful on depending on an implementation versus
> defined interfaces. Even if we could get this initialization done earlier
> for you, unless there was some defined mechanism to force this (ie. the
> openjpa.InitializeEagerly property), I wouldn't count on it. In this
> particular case, the metadata repository is meant for OpenJPA processing.
>
> I know with OpenJPA the lines may not be crystal clear between public
> API's,
> provider SPI's, or internal classes. Of course, since this is an
> open-source project, you are welcome to peruse the complete contents of
> the
> code base and see if a solution is doable or not. I would just be careful
> on being too dependent on a specific implementation.
>
> Kevin
>
> On Fri, May 15, 2009 at 9:30 AM, Heather Sterling <hs...@us.ibm.com>
> wrote:
>
>> Thanks Kevin.
>>
>> Our scenario is that we have added product-specific annotations to the
>> persistent classes. In particular, we have some annotations that we need
>> in
>> our perPersist entity listener to generate unique identifiers before the
>> object is persisted. We're currently initializing all of the metadata at
>> the
>> beginning. We essentially iterate through the persistent classes and
>> create
>> maps that hold this extra information. I guess it's possible for us to
>> lazily load this data in the entity listener if it hasn't been loaded for
>> a
>> particular class. I also looked to see if there was another hook we could
>> potentially use, but didn't see any that seemed to fit the problem.
>>
>>
>> Heather Sterling
>> Systems Management Development
>> Phone: 919-254-7163 T/L: 444-7163
>> Cell: 919-423-3143
>> Email: hsterl@us.ibm.com
>>
>>
>> [image: Inactive hide details for Kevin Sutter ---05/12/2009 12:53:30
>> PM---Heather,]
>> Kevin Sutter ---05/12/2009 12:53:30 PM---Heather,
>>
>>
>>
>>
>> *Kevin Sutter <kw...@gmail.com>*
>>
>> 05/12/2009 12:48 PM
>> Please respond to users
>>
>>
>>
>> To: users@openjpa.apache.org
>> cc:
>> Subject: Re: correct way to load persistent metadata at startup
>>
>>
>> Heather,
>> Good question... :-) This topic has come up recently due to some
>> potential
>> locking issues (serialized access) when reading the metadata repository
>> in
>> a
>> multi-threaded environment. At this point, there is not a clear cut
>> answer
>> for forcing the initialization of the metadata repository. The code for
>> the
>> new openjpa.InitializeEagerly property was committed to trunk last August
>> (after the 1.2.0 release was created), but we've since determined that it
>> may not be complete for all cases. You are welcome to try it out from
>> either the 1.3.x or trunk branches and see if it helps in your particular
>> situation.
>>
>> Let us know what you find out. Also, can you explain your need for
>> getting
>> this data eagerly vs letting the lazy loading process play out? Thanks!
>>
>> Kevin
>>
>>
>>
>> On Mon, May 11, 2009 at 2:40 PM, Heather Sterling <hs...@us.ibm.com>
>> wrote:
>>
>> >
>> >
>> > I am attempting to load all the persistent class metadata eagerly. I
>> > realize this isn't great performance-wise, but I need to do it for the
>> > time-being. I had wanted to call:
>> >
>> > ClassMetaData[] classMetaDatas =
>> > conf.getMetaDataRepositoryInstance().getMetaDatas();
>> >
>> > but realized the data was loaded lazily when nothing came back. I
>> switched
>> > to using:);
>> >
>> > Collection c =
>> conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
>> > true, null);
>> >
>> > which returned the classes to me, but getMetaDatas() still returned
>> > nothing. Finally, I resorted to iterating through the class names,
>> which
>> > seemed to work.
>> >
>> > Set names = conf.getMetaDataRepositoryInstance
>> > ().getPersistentTypeNames(false, null);
>> > if (names != null) {
>> > for (Iterator it = names.iterator(); it.hasNext();) {
>> > String persistentClassname = (String)it.next();
>> > System.out.println("Pre-loading metadata for: " +
>> > persistentClassname);
>> > try {
>> > ClassMetaData cc =
>> conf.getMetaDataRepositoryInstance
>> > ().getMetaData(Class.forName(persistentClassname), null, true);
>> > } catch (ClassNotFoundException e) {
>> > // TODO Auto-generated catch block
>> > e.printStackTrace();
>> > }
>> >
>> > }
>> > }
>> >
>> > I found a link regarding a potential openjpa property called
>> > openjpa.InitializeEagerly (
>> > https://issues.apache.org/jira/browse/OPENJPA-620) but it was never
>> > checked
>> > into a release.
>> >
>> > Given all these options, what is the correct way to load the metadata
>> on
>> > startup?
>> >
>> >
>> > Heather Sterling
>> > Systems Management Development
>> > Phone: 919-254-7163 T/L: 444-7163
>> > Cell: 919-423-3143
>> > Email: hsterl@us.ibm.com
>>
>
>
-----
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/correct-way-to-load-persistent-metadata-at-startup-tp2865060p2911365.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: correct way to load persistent metadata at startup
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Heather,
Interesting use of the OpenJPA metadata processing. Just from your brief
description, I would be careful on depending on an implementation versus
defined interfaces. Even if we could get this initialization done earlier
for you, unless there was some defined mechanism to force this (ie. the
openjpa.InitializeEagerly property), I wouldn't count on it. In this
particular case, the metadata repository is meant for OpenJPA processing.
I know with OpenJPA the lines may not be crystal clear between public API's,
provider SPI's, or internal classes. Of course, since this is an
open-source project, you are welcome to peruse the complete contents of the
code base and see if a solution is doable or not. I would just be careful
on being too dependent on a specific implementation.
Kevin
On Fri, May 15, 2009 at 9:30 AM, Heather Sterling <hs...@us.ibm.com> wrote:
> Thanks Kevin.
>
> Our scenario is that we have added product-specific annotations to the
> persistent classes. In particular, we have some annotations that we need in
> our perPersist entity listener to generate unique identifiers before the
> object is persisted. We're currently initializing all of the metadata at the
> beginning. We essentially iterate through the persistent classes and create
> maps that hold this extra information. I guess it's possible for us to
> lazily load this data in the entity listener if it hasn't been loaded for a
> particular class. I also looked to see if there was another hook we could
> potentially use, but didn't see any that seemed to fit the problem.
>
>
> Heather Sterling
> Systems Management Development
> Phone: 919-254-7163 T/L: 444-7163
> Cell: 919-423-3143
> Email: hsterl@us.ibm.com
>
>
> [image: Inactive hide details for Kevin Sutter ---05/12/2009 12:53:30
> PM---Heather,]
> Kevin Sutter ---05/12/2009 12:53:30 PM---Heather,
>
>
>
>
> *Kevin Sutter <kw...@gmail.com>*
>
> 05/12/2009 12:48 PM
> Please respond to users
>
>
>
> To: users@openjpa.apache.org
> cc:
> Subject: Re: correct way to load persistent metadata at startup
>
>
> Heather,
> Good question... :-) This topic has come up recently due to some
> potential
> locking issues (serialized access) when reading the metadata repository in
> a
> multi-threaded environment. At this point, there is not a clear cut answer
> for forcing the initialization of the metadata repository. The code for
> the
> new openjpa.InitializeEagerly property was committed to trunk last August
> (after the 1.2.0 release was created), but we've since determined that it
> may not be complete for all cases. You are welcome to try it out from
> either the 1.3.x or trunk branches and see if it helps in your particular
> situation.
>
> Let us know what you find out. Also, can you explain your need for getting
> this data eagerly vs letting the lazy loading process play out? Thanks!
>
> Kevin
>
>
>
> On Mon, May 11, 2009 at 2:40 PM, Heather Sterling <hs...@us.ibm.com>
> wrote:
>
> >
> >
> > I am attempting to load all the persistent class metadata eagerly. I
> > realize this isn't great performance-wise, but I need to do it for the
> > time-being. I had wanted to call:
> >
> > ClassMetaData[] classMetaDatas =
> > conf.getMetaDataRepositoryInstance().getMetaDatas();
> >
> > but realized the data was loaded lazily when nothing came back. I
> switched
> > to using:);
> >
> > Collection c = conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
> > true, null);
> >
> > which returned the classes to me, but getMetaDatas() still returned
> > nothing. Finally, I resorted to iterating through the class names, which
> > seemed to work.
> >
> > Set names = conf.getMetaDataRepositoryInstance
> > ().getPersistentTypeNames(false, null);
> > if (names != null) {
> > for (Iterator it = names.iterator(); it.hasNext();) {
> > String persistentClassname = (String)it.next();
> > System.out.println("Pre-loading metadata for: " +
> > persistentClassname);
> > try {
> > ClassMetaData cc = conf.getMetaDataRepositoryInstance
> > ().getMetaData(Class.forName(persistentClassname), null, true);
> > } catch (ClassNotFoundException e) {
> > // TODO Auto-generated catch block
> > e.printStackTrace();
> > }
> >
> > }
> > }
> >
> > I found a link regarding a potential openjpa property called
> > openjpa.InitializeEagerly (
> > https://issues.apache.org/jira/browse/OPENJPA-620) but it was never
> > checked
> > into a release.
> >
> > Given all these options, what is the correct way to load the metadata on
> > startup?
> >
> >
> > Heather Sterling
> > Systems Management Development
> > Phone: 919-254-7163 T/L: 444-7163
> > Cell: 919-423-3143
> > Email: hsterl@us.ibm.com
>
Re: correct way to load persistent metadata at startup
Posted by Heather Sterling <hs...@us.ibm.com>.
Thanks Kevin.
Our scenario is that we have added product-specific annotations to the
persistent classes. In particular, we have some annotations that we need
in our perPersist entity listener to generate unique identifiers before the
object is persisted. We're currently initializing all of the metadata at
the beginning. We essentially iterate through the persistent classes and
create maps that hold this extra information. I guess it's possible for us
to lazily load this data in the entity listener if it hasn't been loaded
for a particular class. I also looked to see if there was another hook we
could potentially use, but didn't see any that seemed to fit the problem.
Heather Sterling
Systems Management Development
Phone: 919-254-7163 T/L: 444-7163
Cell: 919-423-3143
Email: hsterl@us.ibm.com
|---------+---------------------------->
| | Kevin Sutter |
| | <kwsutter@gmail.c|
| | om> |
| | |
| | 05/12/2009 12:48 |
| | PM |
| | Please respond to|
| | users |
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------------------------|
| |
| To: users@openjpa.apache.org |
| cc: |
| Subject: Re: correct way to load persistent metadata at startup |
>----------------------------------------------------------------------------------------------------------------------------------|
Heather,
Good question... :-) This topic has come up recently due to some
potential
locking issues (serialized access) when reading the metadata repository in
a
multi-threaded environment. At this point, there is not a clear cut answer
for forcing the initialization of the metadata repository. The code for
the
new openjpa.InitializeEagerly property was committed to trunk last August
(after the 1.2.0 release was created), but we've since determined that it
may not be complete for all cases. You are welcome to try it out from
either the 1.3.x or trunk branches and see if it helps in your particular
situation.
Let us know what you find out. Also, can you explain your need for getting
this data eagerly vs letting the lazy loading process play out? Thanks!
Kevin
On Mon, May 11, 2009 at 2:40 PM, Heather Sterling <hs...@us.ibm.com>
wrote:
>
>
> I am attempting to load all the persistent class metadata eagerly. I
> realize this isn't great performance-wise, but I need to do it for the
> time-being. I had wanted to call:
>
> ClassMetaData[] classMetaDatas =
> conf.getMetaDataRepositoryInstance().getMetaDatas();
>
> but realized the data was loaded lazily when nothing came back. I
switched
> to using:);
>
> Collection c = conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
> true, null);
>
> which returned the classes to me, but getMetaDatas() still returned
> nothing. Finally, I resorted to iterating through the class names, which
> seemed to work.
>
> Set names = conf.getMetaDataRepositoryInstance
> ().getPersistentTypeNames(false, null);
> if (names != null) {
> for (Iterator it = names.iterator(); it.hasNext();) {
> String persistentClassname = (String)it.next();
> System.out.println("Pre-loading metadata for: " +
> persistentClassname);
> try {
> ClassMetaData cc = conf.getMetaDataRepositoryInstance
> ().getMetaData(Class.forName(persistentClassname), null, true);
> } catch (ClassNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
> }
>
> I found a link regarding a potential openjpa property called
> openjpa.InitializeEagerly (
> https://issues.apache.org/jira/browse/OPENJPA-620) but it was never
> checked
> into a release.
>
> Given all these options, what is the correct way to load the metadata on
> startup?
>
>
> Heather Sterling
> Systems Management Development
> Phone: 919-254-7163 T/L: 444-7163
> Cell: 919-423-3143
> Email: hsterl@us.ibm.com
Re: correct way to load persistent metadata at startup
Posted by Rick Curtis <cu...@gmail.com>.
Simon -
I started looking at the patch you attached to OPENJPA-250 today and I'm
wondering if you had to make any additional changes to get it working
properly in your environment? I applied the patch and I ran a fairly simple
scenario with a number of threads going and I ran into some issues where the
MetaDataRepository wasn't fully initialized yet(The same issue as reported
in this thread). Also, do you recall what the small bugs were that you fixed
in the patch?
-Rick
Simon Droscher wrote:
>
> Rick,
>
> Thanks for reminding me.
>
> We had some great success with a patch I created based on the patch in
> OPENJPA-250.
>
> It needed a bit of work as the code has changed a fair bit since that
> patch was created, and there were also a couple of small bugs in some of
> the patch code.
>
> I've added my new patch (for OpenJPA 1.2.1) to the issue, so take a look
> and let me know your thoughts.
>
> Simon
>
>
--
View this message in context: http://n2.nabble.com/correct-way-to-load-persistent-metadata-at-startup-tp2865060p3233840.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: correct way to load persistent metadata at startup
Posted by Simon Droscher <si...@elasticpath.com>.
Rick,
Thanks for reminding me.
We had some great success with a patch I created based on the patch in
OPENJPA-250.
It needed a bit of work as the code has changed a fair bit since that patch
was created, and there were also a couple of small bugs in some of the patch
code.
I've added my new patch (for OpenJPA 1.2.1) to the issue, so take a look and
let me know your thoughts.
Simon
Rick Curtis wrote:
>
> Simon -
>
> Any luck with trying out that patch? I'm looking into removing the
> synchronization of the MetaDataRepository (As documented by OPENJPA-250)
> and would like to know how this exercise went for you.
>
> -Rick
>
>
> Simon Droscher wrote:
>>
>> I'm trying out the synchronization changes in
>> http://issues.apache.org/jira/browse/OPENJPA-250 to see if that helps my
>> situation (quite a painful patch since a lot has changed since the patch
>> on that issue was created). If it proves helpful I'll contribute a 1.2.1
>> compatible version of the patch.
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/correct-way-to-load-persistent-metadata-at-startup-tp2865060p3215441.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: correct way to load persistent metadata at startup
Posted by Rick Curtis <cu...@gmail.com>.
Simon -
Any luck with trying out that patch? I'm looking into removing the
synchronization of the MetaDataRepository (As documented by OPENJPA-250) and
would like to know how this exercise went for you.
-Rick
Simon Droscher wrote:
>
> I'm trying out the synchronization changes in
> http://issues.apache.org/jira/browse/OPENJPA-250 to see if that helps my
> situation (quite a painful patch since a lot has changed since the patch
> on that issue was created). If it proves helpful I'll contribute a 1.2.1
> compatible version of the patch.
>
>
--
View this message in context: http://n2.nabble.com/correct-way-to-load-persistent-metadata-at-startup-tp2865060p3215234.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: correct way to load persistent metadata at startup
Posted by Simon Droscher <si...@elasticpath.com>.
I'm trying out the synchronization changes in
http://issues.apache.org/jira/browse/OPENJPA-250 to see if that helps my
situation (quite a painful patch since a lot has changed since the patch on
that issue was created). If it proves helpful I'll contribute a 1.2.1
compatible version of the patch.
Kevin Sutter wrote:
>
> No JIRA Issue yet. We're not experiencing deadlocks, we're just
> experiencing some serialized access under certain multi-threaded access.
> I
> haven't pushed on it yet since we just haven't nailed down the exact
> scenario yet. Just not enough time...
>
--
View this message in context: http://n2.nabble.com/correct-way-to-load-persistent-metadata-at-startup-tp2865060p3046053.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: correct way to load persistent metadata at startup
Posted by Simon Droscher <si...@elasticpath.com>.
Kevin,
Thanks for the response.
We weren't experiencing deadlocks either, just a significant number of
threads waiting on a lock for a fairly long time.
Yes we are on WebLogic, and although it comes with a version of JPA we are
not using the WebLogic packaged version, but instead OpenJPA 1.2.1
I may try and get another thread dump, I believe this problem was much
reduced by upgrading the JDK (due to this issue:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6461827)
Simon
Kevin Sutter wrote:
>
> Hi Simon,
>
> On Tue, Jun 2, 2009 at 3:33 PM, Simon Droscher <
> simon.droscher@elasticpath.com> wrote:
>
>>
>> Kevin Sutter wrote:
>> >
>> > This topic has come up recently due to some potential
>> > locking issues (serialized access) when reading the metadata repository
>> in
>> > a
>> > multi-threaded environment.
>> >
>>
>> Do you have any details (JIRA issue?) about the locking issues? We are
>> seeing a lot of locked threads on MetaDataRepository.getMetaData under
>> load
>> with data caching enabled (OpenJPA 1.2.1)
>
>
> No JIRA Issue yet. We're not experiencing deadlocks, we're just
> experiencing some serialized access under certain multi-threaded access.
> I
> haven't pushed on it yet since we just haven't nailed down the exact
> scenario yet. Just not enough time...
>
>
>> Is there anything we can do about this? It is reducing our ability to
>> scale
>> performance.
>
>
> Sorry, I don't know of any work arounds for your situation. And, looking
> at
> your call stack, it looks to be a slightly different problem. I also
> notice
> that you are using the WebLogic environment. What version of OpenJPA are
> you using? You mention 1.2.1 above, but I thought WebLogic used the 1.1.x
> branch of OpenJPA.
>
> Thanks,
> Kevin
>
>
--
View this message in context: http://n2.nabble.com/correct-way-to-load-persistent-metadata-at-startup-tp2865060p3019777.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: correct way to load persistent metadata at startup
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Simon,
On Tue, Jun 2, 2009 at 3:33 PM, Simon Droscher <
simon.droscher@elasticpath.com> wrote:
>
> Kevin Sutter wrote:
> >
> > This topic has come up recently due to some potential
> > locking issues (serialized access) when reading the metadata repository
> in
> > a
> > multi-threaded environment.
> >
>
> Do you have any details (JIRA issue?) about the locking issues? We are
> seeing a lot of locked threads on MetaDataRepository.getMetaData under load
> with data caching enabled (OpenJPA 1.2.1)
No JIRA Issue yet. We're not experiencing deadlocks, we're just
experiencing some serialized access under certain multi-threaded access. I
haven't pushed on it yet since we just haven't nailed down the exact
scenario yet. Just not enough time...
> Is there anything we can do about this? It is reducing our ability to scale
> performance.
Sorry, I don't know of any work arounds for your situation. And, looking at
your call stack, it looks to be a slightly different problem. I also notice
that you are using the WebLogic environment. What version of OpenJPA are
you using? You mention 1.2.1 above, but I thought WebLogic used the 1.1.x
branch of OpenJPA.
Thanks,
Kevin
Here's some of the stack trace:
>
>
> [TDNum36] "[ACTIVE] ExecuteThread: '56' for queue: 'weblogic.kernel.Default
> (self-tuning)'" daemon prio=1 tid=0x36a22b20 nid=0x7c1c runnable
> [0x25cea000..0x25cecda0]
> [TDNum36] at java.lang.Class.isAssignableFrom(Native Method)
> [TDNum36] at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:285)
> [TDNum36] - locked <0x72d44cb8> (a
> org.apache.openjpa.jdbc.meta.MappingRepository)
> [TDNum36] at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:994)
> [TDNum36] at
>
> org.apache.openjpa.kernel.BrokerImpl.newStateManagerImpl(BrokerImpl.java:1179)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:964)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:913)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toRelationFields(AbstractPCData.java:225)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toNestedFields(AbstractPCData.java:192)
> [TDNum36] at
> org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:78)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
> [TDNum36] at
>
> org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> [TDNum36] at
>
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toRelationField(AbstractPCData.java:216)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toNestedField(AbstractPCData.java:150)
> [TDNum36] at
> org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:127)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
> [TDNum36] at
>
> org.apache.openjpa.datacache.DataCacheStoreManager.loadAll(DataCacheStoreManager.java:484)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.loadAll(DelegatingStoreManager.java:121)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:984)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:913)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toRelationFields(AbstractPCData.java:225)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toNestedFields(AbstractPCData.java:192)
> [TDNum36] at
> org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:78)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
> [TDNum36] at
>
> org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> [TDNum36] at
>
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:918)
> [TDNum36] at
> org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2400)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.loadEagerJoin(RelationFieldStrategy.java:541)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.meta.FieldMapping.loadEagerJoin(FieldMapping.java:807)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:967)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:948)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:927)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:364)
> [TDNum36] at
>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> [TDNum36] at
>
> org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:340)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> [TDNum36] at
>
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toRelationField(AbstractPCData.java:216)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toNestedField(AbstractPCData.java:150)
> [TDNum36] at
> org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:127)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
> [TDNum36] at
>
> org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> [TDNum36] at
>
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toRelationField(AbstractPCData.java:216)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toNestedField(AbstractPCData.java:150)
> [TDNum36] at
> org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:127)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
> [TDNum36] at
>
> org.apache.openjpa.datacache.DataCacheStoreManager.loadAll(DataCacheStoreManager.java:484)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.loadAll(DelegatingStoreManager.java:121)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:984)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:913)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toRelationFields(AbstractPCData.java:225)
> [TDNum36] at
>
> org.apache.openjpa.kernel.AbstractPCData.toNestedFields(AbstractPCData.java:192)
> [TDNum36] at
> org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:78)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
> [TDNum36] at
> org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
> [TDNum36] at
>
> org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
> [TDNum36] at
>
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
> [TDNum36] at
>
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> [TDNum36] at
> org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
> [TDNum36] at
>
> org.apache.openjpa.datacache.QueryCacheStoreQuery.fromObjectId(QueryCacheStoreQuery.java:203)
> [TDNum36] at
>
> org.apache.openjpa.datacache.QueryCacheStoreQuery.access$200(QueryCacheStoreQuery.java:58)
> [TDNum36] at
>
> org.apache.openjpa.datacache.QueryCacheStoreQuery$CachedList.get(QueryCacheStoreQuery.java:461)
> [TDNum36] at
>
> org.apache.openjpa.lib.rop.ListResultObjectProvider.getResultObject(ListResultObjectProvider.java:55)
> [TDNum36] at
> org.apache.openjpa.lib.rop.EagerResultList.<init>(EagerResultList.java:36)
> [TDNum36] at
> org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1228)
> [TDNum36] at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
> [TDNum36] at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
> [TDNum36] at
> org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
> [TDNum36] at
> org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
> [TDNum36] at
> org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:252)
> [TDNum36] at
> org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:294)
>
> --
> View this message in context:
> http://n2.nabble.com/correct-way-to-load-persistent-metadata-at-startup-tp2865060p3014458.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: correct way to load persistent metadata at startup
Posted by Simon Droscher <si...@elasticpath.com>.
Kevin Sutter wrote:
>
> This topic has come up recently due to some potential
> locking issues (serialized access) when reading the metadata repository in
> a
> multi-threaded environment.
>
Do you have any details (JIRA issue?) about the locking issues? We are
seeing a lot of locked threads on MetaDataRepository.getMetaData under load
with data caching enabled (OpenJPA 1.2.1)
Is there anything we can do about this? It is reducing our ability to scale
performance. Here's some of the stack trace:
[TDNum36] "[ACTIVE] ExecuteThread: '56' for queue: 'weblogic.kernel.Default
(self-tuning)'" daemon prio=1 tid=0x36a22b20 nid=0x7c1c runnable
[0x25cea000..0x25cecda0]
[TDNum36] at java.lang.Class.isAssignableFrom(Native Method)
[TDNum36] at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:285)
[TDNum36] - locked <0x72d44cb8> (a
org.apache.openjpa.jdbc.meta.MappingRepository)
[TDNum36] at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:994)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.newStateManagerImpl(BrokerImpl.java:1179)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:964)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:913)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toRelationFields(AbstractPCData.java:225)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toNestedFields(AbstractPCData.java:192)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:78)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
[TDNum36] at
org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
[TDNum36] at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toRelationField(AbstractPCData.java:216)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toNestedField(AbstractPCData.java:150)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:127)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
[TDNum36] at
org.apache.openjpa.datacache.DataCacheStoreManager.loadAll(DataCacheStoreManager.java:484)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.loadAll(DelegatingStoreManager.java:121)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:984)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:913)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toRelationFields(AbstractPCData.java:225)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toNestedFields(AbstractPCData.java:192)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:78)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
[TDNum36] at
org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
[TDNum36] at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
[TDNum36] at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:918)
[TDNum36] at
org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:278)
[TDNum36] at
org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2400)
[TDNum36] at
org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.loadEagerJoin(RelationFieldStrategy.java:541)
[TDNum36] at
org.apache.openjpa.jdbc.meta.FieldMapping.loadEagerJoin(FieldMapping.java:807)
[TDNum36] at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:967)
[TDNum36] at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:948)
[TDNum36] at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:927)
[TDNum36] at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:364)
[TDNum36] at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:278)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
[TDNum36] at
org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:340)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
[TDNum36] at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toRelationField(AbstractPCData.java:216)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toNestedField(AbstractPCData.java:150)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:127)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
[TDNum36] at
org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
[TDNum36] at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toRelationField(AbstractPCData.java:216)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toNestedField(AbstractPCData.java:150)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:127)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
[TDNum36] at
org.apache.openjpa.datacache.DataCacheStoreManager.loadAll(DataCacheStoreManager.java:484)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.loadAll(DelegatingStoreManager.java:121)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:984)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.findAll(BrokerImpl.java:913)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toRelationFields(AbstractPCData.java:225)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toNestedFields(AbstractPCData.java:192)
[TDNum36] at
org.apache.openjpa.kernel.AbstractPCData.toField(AbstractPCData.java:78)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.loadField(PCDataImpl.java:197)
[TDNum36] at
org.apache.openjpa.kernel.PCDataImpl.load(PCDataImpl.java:147)
[TDNum36] at
org.apache.openjpa.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:347)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:111)
[TDNum36] at
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:894)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
[TDNum36] at
org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:774)
[TDNum36] at
org.apache.openjpa.datacache.QueryCacheStoreQuery.fromObjectId(QueryCacheStoreQuery.java:203)
[TDNum36] at
org.apache.openjpa.datacache.QueryCacheStoreQuery.access$200(QueryCacheStoreQuery.java:58)
[TDNum36] at
org.apache.openjpa.datacache.QueryCacheStoreQuery$CachedList.get(QueryCacheStoreQuery.java:461)
[TDNum36] at
org.apache.openjpa.lib.rop.ListResultObjectProvider.getResultObject(ListResultObjectProvider.java:55)
[TDNum36] at
org.apache.openjpa.lib.rop.EagerResultList.<init>(EagerResultList.java:36)
[TDNum36] at
org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1228)
[TDNum36] at
org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:990)
[TDNum36] at
org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:805)
[TDNum36] at
org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:775)
[TDNum36] at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:533)
[TDNum36] at
org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:252)
[TDNum36] at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:294)
--
View this message in context: http://n2.nabble.com/correct-way-to-load-persistent-metadata-at-startup-tp2865060p3014458.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: correct way to load persistent metadata at startup
Posted by Kevin Sutter <kw...@gmail.com>.
Heather,
Good question... :-) This topic has come up recently due to some potential
locking issues (serialized access) when reading the metadata repository in a
multi-threaded environment. At this point, there is not a clear cut answer
for forcing the initialization of the metadata repository. The code for the
new openjpa.InitializeEagerly property was committed to trunk last August
(after the 1.2.0 release was created), but we've since determined that it
may not be complete for all cases. You are welcome to try it out from
either the 1.3.x or trunk branches and see if it helps in your particular
situation.
Let us know what you find out. Also, can you explain your need for getting
this data eagerly vs letting the lazy loading process play out? Thanks!
Kevin
On Mon, May 11, 2009 at 2:40 PM, Heather Sterling <hs...@us.ibm.com> wrote:
>
>
> I am attempting to load all the persistent class metadata eagerly. I
> realize this isn't great performance-wise, but I need to do it for the
> time-being. I had wanted to call:
>
> ClassMetaData[] classMetaDatas =
> conf.getMetaDataRepositoryInstance().getMetaDatas();
>
> but realized the data was loaded lazily when nothing came back. I switched
> to using:);
>
> Collection c = conf.getMetaDataRepositoryInstance().loadPersistentTypes(.
> true, null);
>
> which returned the classes to me, but getMetaDatas() still returned
> nothing. Finally, I resorted to iterating through the class names, which
> seemed to work.
>
> Set names = conf.getMetaDataRepositoryInstance
> ().getPersistentTypeNames(false, null);
> if (names != null) {
> for (Iterator it = names.iterator(); it.hasNext();) {
> String persistentClassname = (String)it.next();
> System.out.println("Pre-loading metadata for: " +
> persistentClassname);
> try {
> ClassMetaData cc = conf.getMetaDataRepositoryInstance
> ().getMetaData(Class.forName(persistentClassname), null, true);
> } catch (ClassNotFoundException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> }
> }
>
> I found a link regarding a potential openjpa property called
> openjpa.InitializeEagerly (
> https://issues.apache.org/jira/browse/OPENJPA-620) but it was never
> checked
> into a release.
>
> Given all these options, what is the correct way to load the metadata on
> startup?
>
>
> Heather Sterling
> Systems Management Development
> Phone: 919-254-7163 T/L: 444-7163
> Cell: 919-423-3143
> Email: hsterl@us.ibm.com