Il giorno 05/dic/2012, alle ore 03.48, Michael Dick ha scritto:
> It seems to me that there are two possible use cases here.
>
> 1.) The Broker has been serialized and deserialized. In this case the code
> expects that the LifeCycleEventManager will be serialized with the Broker
> and the saved LCEventManager should be used from that point on (or at least
> until free() is called).
>
> To investigate this case it'd be handy to serialize/deserialize the broker
> and see if the LCEventManager is preserved. If not then perhaps it's a bug
> in serialization. If it is preserved then the lack of a null check isn't
> (necessarily) a red flag.
>
> 2.) The LCEventManager becomes null after doing two bulk delete operations
> (this was mentioned in the original email). Unless the extension to slice
> or your testcase are serializing the broker this is a different issue.
>
> In either case I'd suggest creating a repeatable testcase, or steps to
> reproduce with 'vanilla' OpenJPA and opening a JIRA.
Hi Michael,
I'm able to reproduce the problem only if I use slice.
Actually, it seems that joining the QueryCompilationCache to a slice
configuration cause the problem in object.
I changed the org.apache.openjpa.slice.TestBasic class in order to reproduce
the problem. Please, take a look at the diff below.
--- src/test/java/org/apache/openjpa/slice/TestBasic.java (revision
1415215)
+++ src/test/java/org/apache/openjpa/slice/TestBasic.java (working copy)
@@ -46,8 +46,14 @@
public void setUp() throws Exception {
- super.setUp(PObject.class, Person.class, Address.class, Country.class,
+ super.setUp("openjpa.QueryCompilationCache", "true",
+ PObject.class, Person.class, Address.class, Country.class,
CLEAR_TABLES);
+ EntityManager em = emf.createEntityManager();
+ em.getTransaction().begin();
+ em.createQuery("DELETE FROM PObject p").executeUpdate();
+ em.getTransaction().commit();
+ em.close();
}
Slice should support QueryCompilationCache, shouldn't it?
Please, let me know if I have to open a new issue on Jira.
Best regards,
F.
> -mike
>
>
> On Tue, Dec 4, 2012 at 10:30 AM, Fabio Martelli
> <[email protected]>wrote:
>
>>
>> Il giorno 04/dic/2012, alle ore 17.05, Rick Curtis ha scritto:
>>
>>> I'm not certain the null check is the correct change.... Why aren't we
>>> getting a LifeCycleEventManager on deserialization?
>>
>> Hi Rick,
>> BrokerImpl initialize LifecycleEventManager into the initialize method.
>>
>> From my PPOV, the piece of code that suggest what I wrote in my email is
>> the following
>>
>> ....
>> if (!fromDeserialization) {
>> _lifeEventManager = _conf.getLifecycleEventManagerInstance();
>> .....
>> }
>> .....
>>
>> Now, fromDeserialization is a method's parameter so someone could provide
>> a "true" value for it.
>>
>> In particular, the following chain seems to provide a "true" value for
>> fromDeserialization parameter
>>
>> BrokerImpl.readObject —> AbstractBrokerFactory.initializeBroker —>
>> BrokerImpl.initialize
>>
>> Please tell me if I wrong or I missed something.
>>
>> Best regards,
>> F.
>>
>> Now, since initialize can be called by BrokerFactory.initializeBroker
>>
>>> Thanks,
>>> Rick
>>>
>>> On Tue, Dec 4, 2012 at 3:49 AM, Fabio Martelli <[email protected]
>>> wrote:
>>>
>>>> JDBCStoreQuery
>>>
>>>
>>>
>>>
>>> --
>>> *Rick Curtis*
>>
>>
