You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Fabio Martelli <fa...@gmail.com> on 2012/12/04 10:49:44 UTC
NullPointerException into JDBCStoreQuery
Hi All,
I'm working on a customization around slice (openjpa version 2.3.0-SNAPSHOT).
Checking two subsequent bulk deletes about the same object a NullPointerException will be raised.
The exception has been retrieved at JDBCStoreQuery, row 527.
Considering that, in case of serialization, the LifecycleEventManager can be null, is the attached patch acceptable/applicable?
Please let me know what you think about.
Best regards,
F.
--- openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreQuery.java (revision 1415215)
+++ openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreQuery.java (working copy)
@@ -524,7 +524,7 @@
// execute in-memory so the callbacks are invoked
LifecycleEventManager mgr = ctx.getStoreContext().getBroker()
.getLifecycleEventManager();
- if (mgr.hasDeleteListeners(null, mappings[i]))
+ if (mgr!=null && mgr.hasDeleteListeners(null, mappings[i]))
return null;
}
}
Re: NullPointerException into JDBCStoreQuery
Posted by Albert Lee <al...@gmail.com>.
You may want to open a JIRA and attach a patch to it.
Albert Lee.
On Tue, Dec 4, 2012 at 3:49 AM, Fabio Martelli <fa...@gmail.com>wrote:
> Hi All,
> I'm working on a customization around slice (openjpa version
> 2.3.0-SNAPSHOT).
> Checking two subsequent bulk deletes about the same object a
> NullPointerException will be raised.
>
> The exception has been retrieved at JDBCStoreQuery, row 527.
> Considering that, in case of serialization, the LifecycleEventManager can
> be null, is the attached patch acceptable/applicable?
>
> Please let me know what you think about.
>
> Best regards,
> F.
>
> ---
> openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreQuery.java
> (revision 1415215)
> +++
> openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/kernel/JDBCStoreQuery.java
> (working copy)
> @@ -524,7 +524,7 @@
> // execute in-memory so the callbacks are invoked
> LifecycleEventManager mgr =
> ctx.getStoreContext().getBroker()
> .getLifecycleEventManager();
> - if (mgr.hasDeleteListeners(null, mappings[i]))
> + if (mgr!=null && mgr.hasDeleteListeners(null,
> mappings[i]))
> return null;
> }
> }
>
>
>
>
>
--
Albert Lee.
Re: NullPointerException into JDBCStoreQuery
Posted by Fabio Martelli <fa...@gmail.com>.
Il giorno 05/dic/2012, alle ore 16.05, Michael Dick ha scritto:
> Thanks for diving in and getting a testcase.
>
> Open a new issue on JIRA. I don't remember offhand whether Slice supports
> the compilation cache, but I'd rather document it in JIRA than on the
> mailing list.
>
> Worst case we can always improve the documentation in the JIRA..
Hi Guys,
it seems that slice doesn't support QueryCompilationCache ...
I opened the following two issues related to this problem.
https://issues.apache.org/jira/browse/OPENJPA-2301
https://issues.apache.org/jira/browse/OPENJPA-2302
I hope someone can take a look at the last provided patch (attached to OPENJPA-2302).
Best regards,
F.
>
> -mike
>
>
> On Wed, Dec 5, 2012 at 2:36 AM, Fabio Martelli <fa...@gmail.com>wrote:
>
>>
>> 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 <
>> fabio.martelli@gmail.com>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 <
>> fabio.martelli@gmail.com
>>>>> wrote:
>>>>>
>>>>>> JDBCStoreQuery
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Rick Curtis*
>>>>
>>>>
>>
>>
Re: NullPointerException into JDBCStoreQuery
Posted by Michael Dick <mi...@gmail.com>.
Thanks for diving in and getting a testcase.
Open a new issue on JIRA. I don't remember offhand whether Slice supports
the compilation cache, but I'd rather document it in JIRA than on the
mailing list.
Worst case we can always improve the documentation in the JIRA..
-mike
On Wed, Dec 5, 2012 at 2:36 AM, Fabio Martelli <fa...@gmail.com>wrote:
>
> 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 <
> fabio.martelli@gmail.com>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 <
> fabio.martelli@gmail.com
> >>> wrote:
> >>>
> >>>> JDBCStoreQuery
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> *Rick Curtis*
> >>
> >>
>
>
Re: NullPointerException into JDBCStoreQuery
Posted by Fabio Martelli <fa...@gmail.com>.
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 <fa...@gmail.com>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 <fabio.martelli@gmail.com
>>> wrote:
>>>
>>>> JDBCStoreQuery
>>>
>>>
>>>
>>>
>>> --
>>> *Rick Curtis*
>>
>>
Re: NullPointerException into JDBCStoreQuery
Posted by Michael Dick <mi...@gmail.com>.
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.
-mike
On Tue, Dec 4, 2012 at 10:30 AM, Fabio Martelli <fa...@gmail.com>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 <fabio.martelli@gmail.com
> >wrote:
> >
> >> JDBCStoreQuery
> >
> >
> >
> >
> > --
> > *Rick Curtis*
>
>
Re: NullPointerException into JDBCStoreQuery
Posted by Fabio Martelli <fa...@gmail.com>.
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 <fa...@gmail.com>wrote:
>
>> JDBCStoreQuery
>
>
>
>
> --
> *Rick Curtis*
Re: NullPointerException into JDBCStoreQuery
Posted by Rick Curtis <cu...@gmail.com>.
I'm not certain the null check is the correct change.... Why aren't we
getting a LifeCycleEventManager on deserialization?
Thanks,
Rick
On Tue, Dec 4, 2012 at 3:49 AM, Fabio Martelli <fa...@gmail.com>wrote:
> JDBCStoreQuery
--
*Rick Curtis*