openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marina Vatkina <Marina.Vatk...@Sun.COM>
Subject Re: AW: Forgot subject: Strange Could not locate metadata for the classError?
Date Fri, 23 Mar 2007 21:36:47 GMT
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.getClassMetaDat a(
>>>> JPQLExpressionBuilder.java:164)
>>>>     at
>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMet aD
>>>> ata(JPQLExpressionBuilder.java:142)
>>>>     at
>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMet aD
>>>> ata(JPQLExpressionBuilder.java:211)
>>>>     at
>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMet aD
>>>> ata(JPQLExpressionBuilder.java:181)
>>>>     at
>>>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateTyp 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.populateFromCompilati on
>>>> (ExpressionStoreQuery.java:145)
>>>>     at
>>>> org.apache.openjpa.datacache.QueryCacheStoreQuery.populateFromCompil 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.createNamedQuery
>>>> (EntityManagerImpl.java:785)
>>>>     at
>>>> org.apache.openjpa.persistence.EntityManagerImpl.createNamedQuery
>>>> (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
>>>>>
>>
> 
> 


Mime
View raw message