openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans J. Prueller" <hans.pruel...@gmx.net>
Subject AW: AW: Forgot subject: Strange Could not locate metadata for the classError?
Date Sat, 24 Mar 2007 07:45:20 GMT
I'm not sure if all of you know, but we are utilizing OpenJPA within a
J2EE1.4 container for EJB3 migration purposes. In this "special" case we
are using JPA in "application managed" mode but with synchronized JTA
transactions of the container. 

the current implementation holds a single EMF as a static member in memory
for the whole JVM (there is definitely only 1 VM currently running) and
every SLSB method called starts with creating a new EntityManager ... here
is a code I think Patrick suggested to ensure synchronization of the EM
with the JTA tx of the container:

final BrokerFactory bf = OpenJPAPersistence.toBrokerFactory(emf);

// the broker is part of a  JTA  managed tx
//	 look for an existing Broker on the tx
final Broker b = bf.newBroker(bf.getConfiguration()
			.getConnectionUserName(), bf.getConfiguration()
			.getConnectionPassword(), true,
bf.getConfiguration().getConnectionRetainModeConstant(), true); 

// do some JPA configuration setup. Logic stolen from
// EntityManagerFactoryImpl.
b.setAutoDetach(AutoDetach.DETACH_CLOSE, true);
b.setAutoDetach(AutoDetach.DETACH_ROLLBACK, true);
b.setDetachedNew(false);

return OpenJPAPersistence.toEntityManager(b);


If I understand it right - above lookup code will ensure that there is only
a single EM within a JTA transaction even if I call the method several times
from several methods within the TX.

So does the requirement to set the "multithreaded" property remain by this
usage scenario? 

Hans

> -----Ursprüngliche Nachricht-----
> Von: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
> Gesendet: Freitag, 23. März 2007 23:46
> An: open-jpa-dev@incubator.apache.org
> Betreff: Re: AW: Forgot subject: Strange Could not locate metadata for the
> classError?
> 
> >>> Marc Prud'hommeaux wrote:
> >>>
> >>>> Hans-
> >>>> I don't see how the error could be data-related.
> >>>> One thing: if you are using the same EMF from multiple threads,
> >>>> do  you have the "openjpa.Multithreaded" property explicitly
> >>>> set  to  "true" in your persistence.xml (or however you are
> >>>> configuring  the  EMF)?
> 
> 
> Just to make sure there is no confusion. What I think Marc meant was
> "using the same EM from multiple threads". The openjpa.Multithreading
> property should not apply to multiple threads accessing the
> EntityManagerFactory, which is always thread-safe. The property
> should refer to multiple threads accessing the same EntityManager,
> which is not thread-safe by default.
> 
> Craig
> 
> On Mar 23, 2007, at 2:56 PM, Marina Vatkina wrote:
> 
> > Marc,
> >
> > No, in GlassFish (GF) it shouldn't be the case, but there could be
> > more than 1 EMF created at the same time. The test case uses
> > stateless session bean for accessing EM, so there is no guarantee
> > that the same bean instance serves the 1st method (with a
> > successful persist) and the 2nd (with a failed query). But what's
> > worth noting, that in both cases, mine and Hans's it's the query
> > that causes the problems).
> >
> > BTW, I need to test again without tracing - it can slow things down
> > and hide the problem.
> >
> > regards,
> > -marina
> >
> > Marc Prud'hommeaux wrote:
> >> Marina-
> >> In a normal J2EE app, the same EntityManager will never be used
> >> concurrently from multiple threads. That might also be the case
> >> in  your environment, but it would be interesting to see if the
> >> problem  ever crops up after you enable this property.
> >> On Mar 23, 2007, at 2:36 PM, Marina Vatkina wrote:
> >>> Marc,
> >>>
> >>> Does OpenJPA figures out by itself that it is running in a
> >>> multithreaded environment when used in an app- or web-server? Or
> >>> do  you expect users to always specify this setting when they
> >>> decide to  deploy it to a multi-threaded container?
> >>>
> >>> thanks,
> >>> -marina
> >>>
> >>> Marc Prud'hommeaux wrote:
> >>>
> >>>> Hans-
> >>>> I don't see how the error could be data-related.
> >>>> One thing: if you are using the same EMF from multiple threads,
> >>>> do  you have the "openjpa.Multithreaded" property explicitly
> >>>> set  to  "true" in your persistence.xml (or however you are
> >>>> configuring  the  EMF)? Failure to do this means that access to
> >>>> the broker is   unsynchronized, and I can see how it might lead
> >>>> to a problem like  this.
> >>>> On Mar 23, 2007, at 11:46 AM, Hans J. Prueller wrote:
> >>>>
> >>>>> hm.. sounds strange. could it bet he case that the error
> >>>>> message   openjpa is
> >>>>> printing is only a subsequent error of another one below/before?
> >>>>>
> >>>>> as the JNDI binding did not really work (as you can remember:
> >>>>> everytime I am
> >>>>> accessing the EMF from JNDI it is initialized again and again)
> >>>>> so  I  did a
> >>>>> quick-and-dirty solution for the PoC of OpenJPA integration:
> >>>>> I   saved the EMF
> >>>>> as a static field instead to JNDI, i.e. the first time it is
> >>>>> accessed it is
> >>>>> created - then every client throughout my app should access
> >>>>> the   same static
> >>>>> EMF instance. As there is definitely only a single JVM this
> >>>>> shouldn't make
> >>>>> problems I suggest...
> >>>>>
> >>>>> Additionally I did not see any data in the logs that is
> >>>>> indicating  that a
> >>>>> second EMF is initialized or sth. like that. The strange thing
> >>>>> is  that it
> >>>>> worked several invocations before and after .. could it be a
> >>>>> data- related
> >>>>> problem? Anyway, I was not able to reproduce the error....
> >>>>>
> >>>>> Hans
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -----Ursprüngliche Nachricht-----
> >>>>>> Von: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] Im
> >>>>>> Auftrag von
> >>>>>> Marc Prud'hommeaux
> >>>>>> Gesendet: Freitag, 23. März 2007 17:59
> >>>>>> An: open-jpa-dev@incubator.apache.org
> >>>>>> Betreff: Re: Forgot subject: Strange Could not locate
> >>>>>> metadata  for  the
> >>>>>> classError?
> >>>>>>
> >>>>>> Hans-
> >>>>>>
> >>>>>> There are only two possible conditions in which I can see this
> >>>>>> problem happening:
> >>>>>>
> >>>>>> 1. the class "com.lbslogics.ims.model.PositionLog" is not
> >>>>>> loadable in
> >>>>>> the current environment's classloader.
> >>>>>> 2. the PositionLog class was registered with the
> >>>>>> MetaDataRepository
> >>>>>> during the lookup process.
> >>>>>>
> >>>>>> Since the same code has been executed hundreds of times via
> >>>>>> the MDB
> >>>>>> prior to this error, neither of these seems very plausible.
> >>>>>> Are you
> >>>>>> sure that the exact same EntityManagerFactory (in the same
> >>>>>> JVM) has
> >>>>>> been used prior to this error to execute the same method? The
> >>>>>> fact
> >>>>>> that it looks like we are parsing the query for the first
> >>>>>> time  (since
> >>>>>> it appears we are making a new internal parse compilation from
> >>>>>> it)
> >>>>>> makes it look like that particular method has not yet been
> >>>>>> called for
> >>>>>> that EntityManager's EntityManagerFactory.
> >>>>>>
> >>>>>> If this is something you can reproduce, it would be
> >>>>>> interesting  if we
> >>>>>> could see more logging output (enabled by setting the "kodo.Log"
> >>>>>> property to "DefaultLevel=TRACE"), especially those messages
> >>>>>> that are
> >>>>>> on the MetaData channel.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Mar 23, 2007, at 5:57 AM, Hans J. Prueller wrote:
> >>>>>>
> >>>>>>> full stack trace (up until application specific stuff) is:
> >>>>>>>
> >>>>>>> 2007-03-22 21:34:53,287 : SEVERE : WorkThread-2/34 :
> >>>>>>> Logger.log :
> >>>>>>> system exception in business method:
> >>>>>>> <4|true|0.9.7-incubating-SNAPSHOT>
> >>>>>>> org.apache.openjpa.persistence.ArgumentException: Could
not
> >>>>>>> locate
> >>>>>>> metadata for the class using alias "PositionLog". Registered
> >>>>>>> alias
> >>>>>>> mappings: "{PositionLog=[class
> >>>>>>> com.lbslogics.ims.model.PositionLog]}"
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.meta.MetaDataRepository.getMetaData
> >>>>>>> (MetaDataRepository.java:345)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMet
> >>>>>>> aD at a(
> >>>>>>> JPQLExpressionBuilder.java:164)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClas
> >>>>>>> sM et aD
> >>>>>>> ata(JPQLExpressionBuilder.java:142)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidat
> >>>>>>> eM et aD
> >>>>>>> ata(JPQLExpressionBuilder.java:211)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidat
> >>>>>>> eM et aD
> >>>>>>> ata(JPQLExpressionBuilder.java:181)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidat
> >>>>>>> eT yp e(
> >>>>>>> JPQLExpressionBuilder.java:174)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access
> >>>>>>> $500(JPQLExpressionBuilder.java:61)
> >>>>>>>     at org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder
> >>>>>>> $ParsedJPQL.populate(JPQLExpressionBuilder.java:1668)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.jpql.JPQLParser.populate
> >>>>>>> (JPQLParser.java:52)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompi
> >>>>>>> la ti on
> >>>>>>> (ExpressionStoreQuery.java:145)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.datacache.QueryCacheStoreQuery.populateFromCo
> >>>>>>> mp il at
> >>>>>>> ion(QueryCacheStoreQuery.java:237)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.QueryImpl.newCompilation
> >>>>>>> (QueryImpl.java: 644)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.QueryImpl.compilationFromCache
> >>>>>>> (QueryImpl.java:625)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.QueryImpl.compileForCompilation
> >>>>>>> (QueryImpl.java:591)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.kernel.QueryImpl.compileForExecutor
> >>>>>>> (QueryImpl.java:653)
> >>>>>>>     at org.apache.openjpa.kernel.QueryImpl.compile
> >>>>>>> (QueryImpl.java:560)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuer
> >>>>>>> y
> >>>>>>> (EntityManagerImpl.java:785)
> >>>>>>>     at
> >>>>>>> org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuer
> >>>>>>> y
> >>>>>>> (EntityManagerImpl.java:62)
> >>>>>>>     at
> >>>>>>
> >>>>>>
> >>>>>> com.lbslogics.ims.model.PositionLog.findById(PositionLog.java:
> >>>>>> 175)
> >>>>>>
> >>>>>>>     at
> >>>>>>> com.lbslogics.ims.persistence.ejb.EventBean.getPositionLog
> >>>>>>> (EventBean.java:2875)
> >>>>>>>          [ ... some more ]
> >>>>>>>
> >>>>>>> The corresponding EventBean is a SLSB (EJB2.1) and the
> >>>>>>> method  looks
> >>>>>>> like
> >>>>>>> that:
> >>>>>>>
> >>>>>>>         /**
> >>>>>>>      *
> >>>>>>>      * @return
> >>>>>>>      */
> >>>>>>>     public PositionLog getPositionLog(final EntityManager
em) {
> >>>>>>>         final PositionLog log = PositionLog.findById(em,
> >>>>>>
> >>>>>>
> >>>>>> getPositionLogId
> >>>>>>
> >>>>>>> ());
> >>>>>>>         return log;
> >>>>>>>     }
> >>>>>>>
> >>>>>>> and the Positionlog.findById is a static method which
> >>>>>>> encapsulates
> >>>>>>> some
> >>>>>>> of the "technical work":
> >>>>>>>
> >>>>>>>         public static PositionLog findById(EntityManager
em,
> >>>>>>> Long
> >>>>>>> plId)
> >>>>>>> {
> >>>>>>>         Query q = em.createNamedQuery("PositionLog.byId");
> >>>>>>>         q.setParameter("id", plId);
> >>>>>>>
> >>>>>>>         try {
> >>>>>>>             return (PositionLog) q.getSingleResult();
> >>>>>>>         } catch (javax.persistence.NoResultException e)
{
> >>>>>>>             logger.finest("findById: did not find result
for
> >>>>>
> >>>>>
> >>>>> id=" +
> >>>>>
> >>>>>> plId);
> >>>>>>
> >>>>>>>             return null;
> >>>>>>>         }
> >>>>>>>     }
> >>>>>>>
> >>>>>>> This method or better the top-level entry point of this
> >>>>>>> method is
> >>>>>>> called
> >>>>>>> several hundred times for different records, all invoked
by a
> >>>>>>> MDB.
> >>>>>>> Could
> >>>>>>> it be some concurrency issue because after several hundred
> >>>>>>> invocations
> >>>>>>> only a single exception occured?
> >>>>>>>
> >>>>>>> Hans
> >>>>>>>
> >>>>>>> Am Freitag, den 23.03.2007, 05:48 -0700 schrieb Patrick
Linskey:
> >>>>>>>
> >>>>>>>> Could you post the full stack trace, and maybe some
code
> >>>>>>>> showing  how
> >>>>>>>> you're invoking the JPA APIs?
> >>>>>>>>
> >>>>>>>> -Patrick
> >>>>>>>>
> >>>>>
> >>>
> >
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!



Mime
View raw message