You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by coloradoflyer <op...@parallelsw.com> on 2009/03/12 04:37:35 UTC
openejb3.1 merge
Hi all,
I wrote a small app to look at openejb and am having an issue with one of
the relationships.
Before posting too much code I wanted to see if anything is obviously wrong.
The application has about 5 tables, I'm creating one row and building a
OneToMany association to another pre-existing entity, this all works without
issue. The next step in my test case was to update the OneToMany to another
pre-existing entity. All of the fields are already populated and I'm
invoking the setter on the entity. Once this is done, I invoked the merge
method on the Injected entityManager. The object returned from this is in
tact, and has the association, but one of the fields in the associated
object is set to null.
I'm working in OpenJPA 1.1, OpenEJB3.1, database is Postgres.
The code is inside a local Stateless session bean method.
The foreign key association for the onetomany is updated, and if I invoke
the finder to reload the object, it all loads properly, and the null field
is populated properly.
finally, in order to ensure this was an openejb problem and not something
specific to openjpa, I broke the code out of the stateless session, and ran
the same code with the transaction management in place without openejb.
Basically, the entity ended up with the proper field value after the merge.
thanks for any info/help.
--
View this message in context: http://www.nabble.com/openejb3.1-merge-tp22469332p22469332.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: openejb3.1 merge
Posted by David Blevins <da...@visi.com>.
On Mar 30, 2009, at 11:46 PM, coloradoflyer wrote:
>
> I missed these last 2 comments. First, I really don't want this to
> be a
> stateful bean, there is no state in here and it should not be using
> that
> resource.
That's ok. I mentioned that as you said you ran the same code with
OpenJPA directly and didn't see the same issue. In that scenario you
were likely using the same EntityManager for all persistence
operations and avoiding the detach as a result, which is definitely a
state-based approach. If you wanted things to run the same way, an
EXTENDED persistence context is equivalent to that scenario.
Alternatively increasing the scope of the JTA transaction would have
the same effect; lifecycle of a TRANSACTION persistence context is
tied to the transaction, which will be one transaction per EJB call
(and hence one EntityManager instance per call) unless there is a
larger transaction to tie those EJB invocations together.
Regardless, the detach approach should work fine. I'm not sure what
might be going on with the detached object merge. Cc'ing the OpenJPA
list as they might have a better idea.
For their benefit here's the sample app that reproduces the detach/
merge issue: http://www.nabble.com/file/p22509703/testerror.jar
-David
> The entity I'm passing into the method to be merged is fully
> hydrated and
> just being updated, should I use something other than merge to
> update the
> object? It is for sure detached.
>
> Second, This was not using a lazy loaded value, remember, when it was
> loaded, I saw a value, but when I went in to merge (update) the
> entity it
> did the update in the db, but the value came back as empty. It
> seems like a
> problem that when a merge is done an attribute is lazy loaded? but
> when
> query/load the attribute is not lazy loaded.
>
> -chris
>
>
> Jonathan Gallimore-2 wrote:
>>
>> You're absolutely spot on David, making those changes worked here. I
>> didn't even think of that, oops! Perhaps we could add a warning to
>> the
>> JtaEntityManager if the entity is detached, assuming that's
>> something we
>> could detect?
>>
>> Jon
>>
>>
>> David Blevins wrote:
>>> Haven't had a chance to look at the issue, but it's starting to
>>> sound
>>> like a detach. Per spec, when the transaction ends, all objects
>>> pulled from a TRANSACTION scoped PersistenceContext are detached and
>>> no more data will be read into them. This can lead to strange state
>>> as most vendors do lazy loading and therefore any fields not loaded
>>> after the detach will stay unset.
>>>
>>> Try switching your Stateless bean to a Stateful and changing your
>>> PersistenceContextType.TRANSACTION to
>>> PersistenceContextType.EXTENDED.
>>>
>>> -David
>>>
>>>
>>> On Mar 16, 2009, at 2:00 PM, Jonathan Gallimore wrote:
>>>
>>>> Yes, you did mention that - should help narrow down the problem ;-)
>>>>
>>>> I tried your code with both HSQLDB and Postgresql with the same
>>>> result on both. org.apache.openejb.persistence.JtaEntityManager is
>>>> the class that gets injected into _entityManager in your Session
>>>> bean, and this is a wrapper around the OpenJPA entity manager. I'm
>>>> wondering whether we're setting something up differently to how
>>>> you're using OpenJPA on its own. I'm currently checking out OpenJPA
>>>> to delve into this further.
>>>>
>>>> Cheers
>>>>
>>>> Jon
>>>>
>>>>
>>>> coloradoflyer wrote:
>>>>> Hi Jon,
>>>>>
>>>>> Thanks for your help. I'm not sure if I mentioned this or not,
>>>>> but
>>>>> I did
>>>>> try this out in a test case using only openjpa and I did not see
>>>>> the
>>>>> same
>>>>> behavior. I did not try it using any other database, but I don't
>>>>> think this
>>>>> is a problem in that part of the code. I did look at the sql
>>>>> generated, and
>>>>> it looks like all of the columns are being selected. One other
>>>>> thing I did,
>>>>> I downloaded the openejb source, and started looking through it,
>>>>> but
>>>>> I'm not
>>>>> familiar with the code at all and was hoping the problem would
>>>>> manifest
>>>>> itself in my code somewhere.... Thanks for your help, please
>>>>> let me
>>>>> know
>>>>> when you find the problem.
>>>>>
>>>>> -chris
>>>>>
>>>>>
>>>>> Jonathan Gallimore-2 wrote:
>>>>>
>>>>>> I've managed to reproduce the issue with your code (many thanks
>>>>>> for
>>>>>> that!). I'm not sure why its happening, your code looks ok to me,
>>>>>> so I'm going to dig deeper to try and figure out what's going on.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>> coloradoflyer wrote:
>>>>>>
>>>>>>> Hi Jon/all,
>>>>>>>
>>>>>>> I attached a jar with the test case. Basically, there are 5
>>>>>>> source files
>>>>>>> in
>>>>>>> here and a sql script to create the entities.
>>>>>>> The interface for the stateless session bean, the concrete class
>>>>>>> for it.
>>>>>>> The 2 Entites, and the Test case. Its pretty small.
>>>>>>>
>>>>>>> If you take a look at the test case, if it passes, that in
>>>>>>> itself
>>>>>>> displays
>>>>>>> the problem. The test case is TestAudioServices, and the line
>>>>>>> that
>>>>>>> **should** fail is line 40, it looks for null for the name of
>>>>>>> the
>>>>>>> status
>>>>>>> (which should never be null). The proof that this case
>>>>>>> displays the
>>>>>>> problem, is on line 43, basically line 42 reloads the entity by
>>>>>>> its id,
>>>>>>> and
>>>>>>> then checks to see if the status now is not null, one of those 2
>>>>>>> lines
>>>>>>> (41
>>>>>>> or 43) should fail.
>>>>>>>
>>>>>>> These are the lines in question:
>>>>>>> file = stateless.update(file);
>>>>>>> assertNull(file.getAudioFileStatus().getName());
>>>>>>> file = stateless.findById(file.getId());
>>>>>>> assertNotNull(file.getAudioFileStatus().getName());
>>>>>>>
>>>>>>> Thanks for looking into this, I keep thinking I'm going to find
>>>>>>> something
>>>>>>> wrong in my code, but I'm not seeing it so far, and its
>>>>>>> relatively
>>>>>>> trivial
>>>>>>> now.
>>>>>>> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
>>>>>>> -chris
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/openejb3.1-merge-tp22469332p22799300.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: openejb3.1 merge
Posted by David Blevins <da...@visi.com>.
On Mar 30, 2009, at 11:46 PM, coloradoflyer wrote:
>
> I missed these last 2 comments. First, I really don't want this to
> be a
> stateful bean, there is no state in here and it should not be using
> that
> resource.
That's ok. I mentioned that as you said you ran the same code with
OpenJPA directly and didn't see the same issue. In that scenario you
were likely using the same EntityManager for all persistence
operations and avoiding the detach as a result, which is definitely a
state-based approach. If you wanted things to run the same way, an
EXTENDED persistence context is equivalent to that scenario.
Alternatively increasing the scope of the JTA transaction would have
the same effect; lifecycle of a TRANSACTION persistence context is
tied to the transaction, which will be one transaction per EJB call
(and hence one EntityManager instance per call) unless there is a
larger transaction to tie those EJB invocations together.
Regardless, the detach approach should work fine. I'm not sure what
might be going on with the detached object merge. Cc'ing the OpenJPA
list as they might have a better idea.
For their benefit here's the sample app that reproduces the detach/
merge issue: http://www.nabble.com/file/p22509703/testerror.jar
-David
> The entity I'm passing into the method to be merged is fully
> hydrated and
> just being updated, should I use something other than merge to
> update the
> object? It is for sure detached.
>
> Second, This was not using a lazy loaded value, remember, when it was
> loaded, I saw a value, but when I went in to merge (update) the
> entity it
> did the update in the db, but the value came back as empty. It
> seems like a
> problem that when a merge is done an attribute is lazy loaded? but
> when
> query/load the attribute is not lazy loaded.
>
> -chris
>
>
> Jonathan Gallimore-2 wrote:
>>
>> You're absolutely spot on David, making those changes worked here. I
>> didn't even think of that, oops! Perhaps we could add a warning to
>> the
>> JtaEntityManager if the entity is detached, assuming that's
>> something we
>> could detect?
>>
>> Jon
>>
>>
>> David Blevins wrote:
>>> Haven't had a chance to look at the issue, but it's starting to
>>> sound
>>> like a detach. Per spec, when the transaction ends, all objects
>>> pulled from a TRANSACTION scoped PersistenceContext are detached and
>>> no more data will be read into them. This can lead to strange state
>>> as most vendors do lazy loading and therefore any fields not loaded
>>> after the detach will stay unset.
>>>
>>> Try switching your Stateless bean to a Stateful and changing your
>>> PersistenceContextType.TRANSACTION to
>>> PersistenceContextType.EXTENDED.
>>>
>>> -David
>>>
>>>
>>> On Mar 16, 2009, at 2:00 PM, Jonathan Gallimore wrote:
>>>
>>>> Yes, you did mention that - should help narrow down the problem ;-)
>>>>
>>>> I tried your code with both HSQLDB and Postgresql with the same
>>>> result on both. org.apache.openejb.persistence.JtaEntityManager is
>>>> the class that gets injected into _entityManager in your Session
>>>> bean, and this is a wrapper around the OpenJPA entity manager. I'm
>>>> wondering whether we're setting something up differently to how
>>>> you're using OpenJPA on its own. I'm currently checking out OpenJPA
>>>> to delve into this further.
>>>>
>>>> Cheers
>>>>
>>>> Jon
>>>>
>>>>
>>>> coloradoflyer wrote:
>>>>> Hi Jon,
>>>>>
>>>>> Thanks for your help. I'm not sure if I mentioned this or not,
>>>>> but
>>>>> I did
>>>>> try this out in a test case using only openjpa and I did not see
>>>>> the
>>>>> same
>>>>> behavior. I did not try it using any other database, but I don't
>>>>> think this
>>>>> is a problem in that part of the code. I did look at the sql
>>>>> generated, and
>>>>> it looks like all of the columns are being selected. One other
>>>>> thing I did,
>>>>> I downloaded the openejb source, and started looking through it,
>>>>> but
>>>>> I'm not
>>>>> familiar with the code at all and was hoping the problem would
>>>>> manifest
>>>>> itself in my code somewhere.... Thanks for your help, please
>>>>> let me
>>>>> know
>>>>> when you find the problem.
>>>>>
>>>>> -chris
>>>>>
>>>>>
>>>>> Jonathan Gallimore-2 wrote:
>>>>>
>>>>>> I've managed to reproduce the issue with your code (many thanks
>>>>>> for
>>>>>> that!). I'm not sure why its happening, your code looks ok to me,
>>>>>> so I'm going to dig deeper to try and figure out what's going on.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>> coloradoflyer wrote:
>>>>>>
>>>>>>> Hi Jon/all,
>>>>>>>
>>>>>>> I attached a jar with the test case. Basically, there are 5
>>>>>>> source files
>>>>>>> in
>>>>>>> here and a sql script to create the entities.
>>>>>>> The interface for the stateless session bean, the concrete class
>>>>>>> for it.
>>>>>>> The 2 Entites, and the Test case. Its pretty small.
>>>>>>>
>>>>>>> If you take a look at the test case, if it passes, that in
>>>>>>> itself
>>>>>>> displays
>>>>>>> the problem. The test case is TestAudioServices, and the line
>>>>>>> that
>>>>>>> **should** fail is line 40, it looks for null for the name of
>>>>>>> the
>>>>>>> status
>>>>>>> (which should never be null). The proof that this case
>>>>>>> displays the
>>>>>>> problem, is on line 43, basically line 42 reloads the entity by
>>>>>>> its id,
>>>>>>> and
>>>>>>> then checks to see if the status now is not null, one of those 2
>>>>>>> lines
>>>>>>> (41
>>>>>>> or 43) should fail.
>>>>>>>
>>>>>>> These are the lines in question:
>>>>>>> file = stateless.update(file);
>>>>>>> assertNull(file.getAudioFileStatus().getName());
>>>>>>> file = stateless.findById(file.getId());
>>>>>>> assertNotNull(file.getAudioFileStatus().getName());
>>>>>>>
>>>>>>> Thanks for looking into this, I keep thinking I'm going to find
>>>>>>> something
>>>>>>> wrong in my code, but I'm not seeing it so far, and its
>>>>>>> relatively
>>>>>>> trivial
>>>>>>> now.
>>>>>>> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
>>>>>>> -chris
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/openejb3.1-merge-tp22469332p22799300.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: openejb3.1 merge
Posted by coloradoflyer <op...@parallelsw.com>.
I missed these last 2 comments. First, I really don't want this to be a
stateful bean, there is no state in here and it should not be using that
resource.
The entity I'm passing into the method to be merged is fully hydrated and
just being updated, should I use something other than merge to update the
object? It is for sure detached.
Second, This was not using a lazy loaded value, remember, when it was
loaded, I saw a value, but when I went in to merge (update) the entity it
did the update in the db, but the value came back as empty. It seems like a
problem that when a merge is done an attribute is lazy loaded? but when
query/load the attribute is not lazy loaded.
-chris
Jonathan Gallimore-2 wrote:
>
> You're absolutely spot on David, making those changes worked here. I
> didn't even think of that, oops! Perhaps we could add a warning to the
> JtaEntityManager if the entity is detached, assuming that's something we
> could detect?
>
> Jon
>
>
> David Blevins wrote:
>> Haven't had a chance to look at the issue, but it's starting to sound
>> like a detach. Per spec, when the transaction ends, all objects
>> pulled from a TRANSACTION scoped PersistenceContext are detached and
>> no more data will be read into them. This can lead to strange state
>> as most vendors do lazy loading and therefore any fields not loaded
>> after the detach will stay unset.
>>
>> Try switching your Stateless bean to a Stateful and changing your
>> PersistenceContextType.TRANSACTION to PersistenceContextType.EXTENDED.
>>
>> -David
>>
>>
>> On Mar 16, 2009, at 2:00 PM, Jonathan Gallimore wrote:
>>
>>> Yes, you did mention that - should help narrow down the problem ;-)
>>>
>>> I tried your code with both HSQLDB and Postgresql with the same
>>> result on both. org.apache.openejb.persistence.JtaEntityManager is
>>> the class that gets injected into _entityManager in your Session
>>> bean, and this is a wrapper around the OpenJPA entity manager. I'm
>>> wondering whether we're setting something up differently to how
>>> you're using OpenJPA on its own. I'm currently checking out OpenJPA
>>> to delve into this further.
>>>
>>> Cheers
>>>
>>> Jon
>>>
>>>
>>> coloradoflyer wrote:
>>>> Hi Jon,
>>>>
>>>> Thanks for your help. I'm not sure if I mentioned this or not, but
>>>> I did
>>>> try this out in a test case using only openjpa and I did not see the
>>>> same
>>>> behavior. I did not try it using any other database, but I don't
>>>> think this
>>>> is a problem in that part of the code. I did look at the sql
>>>> generated, and
>>>> it looks like all of the columns are being selected. One other
>>>> thing I did,
>>>> I downloaded the openejb source, and started looking through it, but
>>>> I'm not
>>>> familiar with the code at all and was hoping the problem would manifest
>>>> itself in my code somewhere.... Thanks for your help, please let me
>>>> know
>>>> when you find the problem.
>>>>
>>>> -chris
>>>>
>>>>
>>>> Jonathan Gallimore-2 wrote:
>>>>
>>>>> I've managed to reproduce the issue with your code (many thanks for
>>>>> that!). I'm not sure why its happening, your code looks ok to me,
>>>>> so I'm going to dig deeper to try and figure out what's going on.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>> coloradoflyer wrote:
>>>>>
>>>>>> Hi Jon/all,
>>>>>>
>>>>>> I attached a jar with the test case. Basically, there are 5
>>>>>> source files
>>>>>> in
>>>>>> here and a sql script to create the entities.
>>>>>> The interface for the stateless session bean, the concrete class
>>>>>> for it.
>>>>>> The 2 Entites, and the Test case. Its pretty small.
>>>>>>
>>>>>> If you take a look at the test case, if it passes, that in itself
>>>>>> displays
>>>>>> the problem. The test case is TestAudioServices, and the line that
>>>>>> **should** fail is line 40, it looks for null for the name of the
>>>>>> status
>>>>>> (which should never be null). The proof that this case displays the
>>>>>> problem, is on line 43, basically line 42 reloads the entity by
>>>>>> its id,
>>>>>> and
>>>>>> then checks to see if the status now is not null, one of those 2
>>>>>> lines
>>>>>> (41
>>>>>> or 43) should fail.
>>>>>>
>>>>>> These are the lines in question:
>>>>>> file = stateless.update(file);
>>>>>> assertNull(file.getAudioFileStatus().getName());
>>>>>> file = stateless.findById(file.getId());
>>>>>> assertNotNull(file.getAudioFileStatus().getName());
>>>>>>
>>>>>> Thanks for looking into this, I keep thinking I'm going to find
>>>>>> something
>>>>>> wrong in my code, but I'm not seeing it so far, and its relatively
>>>>>> trivial
>>>>>> now.
>>>>>> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
>>>>>> -chris
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/openejb3.1-merge-tp22469332p22799300.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: openejb3.1 merge
Posted by David Blevins <da...@visi.com>.
On Mar 17, 2009, at 1:35 PM, Jonathan Gallimore wrote:
> You're absolutely spot on David, making those changes worked here. I
> didn't even think of that, oops! Perhaps we could add a warning to
> the JtaEntityManager if the entity is detached, assuming that's
> something we could detect?
Not something we could detect in absolute terms, though detaching will
always happen at the end of a transaction for a TRANSACTION
persistence context. Maybe there's some way we can check to see if an
entity manager was used in a transaction and log a "Persistent
Entities will now be detached -- see http://openejb.apache.org/3.0/jpa-concepts.html
" on debug or something.
-David
> David Blevins wrote:
>> Haven't had a chance to look at the issue, but it's starting to
>> sound like a detach. Per spec, when the transaction ends, all
>> objects pulled from a TRANSACTION scoped PersistenceContext are
>> detached and no more data will be read into them. This can lead to
>> strange state as most vendors do lazy loading and therefore any
>> fields not loaded after the detach will stay unset.
>>
>> Try switching your Stateless bean to a Stateful and changing your
>> PersistenceContextType.TRANSACTION to
>> PersistenceContextType.EXTENDED.
>>
>> -David
>>
>>
>> On Mar 16, 2009, at 2:00 PM, Jonathan Gallimore wrote:
>>
>>> Yes, you did mention that - should help narrow down the problem ;-)
>>>
>>> I tried your code with both HSQLDB and Postgresql with the same
>>> result on both. org.apache.openejb.persistence.JtaEntityManager is
>>> the class that gets injected into _entityManager in your Session
>>> bean, and this is a wrapper around the OpenJPA entity manager. I'm
>>> wondering whether we're setting something up differently to how
>>> you're using OpenJPA on its own. I'm currently checking out
>>> OpenJPA to delve into this further.
>>>
>>> Cheers
>>>
>>> Jon
>>>
>>>
>>> coloradoflyer wrote:
>>>> Hi Jon,
>>>>
>>>> Thanks for your help. I'm not sure if I mentioned this or not,
>>>> but I did
>>>> try this out in a test case using only openjpa and I did not see
>>>> the same
>>>> behavior. I did not try it using any other database, but I don't
>>>> think this
>>>> is a problem in that part of the code. I did look at the sql
>>>> generated, and
>>>> it looks like all of the columns are being selected. One other
>>>> thing I did,
>>>> I downloaded the openejb source, and started looking through it,
>>>> but I'm not
>>>> familiar with the code at all and was hoping the problem would
>>>> manifest
>>>> itself in my code somewhere.... Thanks for your help, please let
>>>> me know
>>>> when you find the problem.
>>>>
>>>> -chris
>>>>
>>>>
>>>> Jonathan Gallimore-2 wrote:
>>>>
>>>>> I've managed to reproduce the issue with your code (many thanks
>>>>> for that!). I'm not sure why its happening, your code looks ok
>>>>> to me, so I'm going to dig deeper to try and figure out what's
>>>>> going on.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>> coloradoflyer wrote:
>>>>>
>>>>>> Hi Jon/all,
>>>>>>
>>>>>> I attached a jar with the test case. Basically, there are 5
>>>>>> source files
>>>>>> in
>>>>>> here and a sql script to create the entities.
>>>>>> The interface for the stateless session bean, the concrete
>>>>>> class for it.
>>>>>> The 2 Entites, and the Test case. Its pretty small.
>>>>>>
>>>>>> If you take a look at the test case, if it passes, that in itself
>>>>>> displays
>>>>>> the problem. The test case is TestAudioServices, and the line
>>>>>> that
>>>>>> **should** fail is line 40, it looks for null for the name of
>>>>>> the status
>>>>>> (which should never be null). The proof that this case
>>>>>> displays the
>>>>>> problem, is on line 43, basically line 42 reloads the entity by
>>>>>> its id,
>>>>>> and
>>>>>> then checks to see if the status now is not null, one of those
>>>>>> 2 lines
>>>>>> (41
>>>>>> or 43) should fail.
>>>>>>
>>>>>> These are the lines in question:
>>>>>> file = stateless.update(file);
>>>>>> assertNull(file.getAudioFileStatus().getName());
>>>>>> file = stateless.findById(file.getId());
>>>>>> assertNotNull(file.getAudioFileStatus().getName());
>>>>>>
>>>>>> Thanks for looking into this, I keep thinking I'm going to find
>>>>>> something
>>>>>> wrong in my code, but I'm not seeing it so far, and its
>>>>>> relatively
>>>>>> trivial
>>>>>> now.
>>>>>> http://www.nabble.com/file/p22509703/testerror.jar
>>>>>> testerror.jar -chris
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: openejb3.1 merge
Posted by Jonathan Gallimore <jo...@gmail.com>.
You're absolutely spot on David, making those changes worked here. I
didn't even think of that, oops! Perhaps we could add a warning to the
JtaEntityManager if the entity is detached, assuming that's something we
could detect?
Jon
David Blevins wrote:
> Haven't had a chance to look at the issue, but it's starting to sound
> like a detach. Per spec, when the transaction ends, all objects
> pulled from a TRANSACTION scoped PersistenceContext are detached and
> no more data will be read into them. This can lead to strange state
> as most vendors do lazy loading and therefore any fields not loaded
> after the detach will stay unset.
>
> Try switching your Stateless bean to a Stateful and changing your
> PersistenceContextType.TRANSACTION to PersistenceContextType.EXTENDED.
>
> -David
>
>
> On Mar 16, 2009, at 2:00 PM, Jonathan Gallimore wrote:
>
>> Yes, you did mention that - should help narrow down the problem ;-)
>>
>> I tried your code with both HSQLDB and Postgresql with the same
>> result on both. org.apache.openejb.persistence.JtaEntityManager is
>> the class that gets injected into _entityManager in your Session
>> bean, and this is a wrapper around the OpenJPA entity manager. I'm
>> wondering whether we're setting something up differently to how
>> you're using OpenJPA on its own. I'm currently checking out OpenJPA
>> to delve into this further.
>>
>> Cheers
>>
>> Jon
>>
>>
>> coloradoflyer wrote:
>>> Hi Jon,
>>>
>>> Thanks for your help. I'm not sure if I mentioned this or not, but
>>> I did
>>> try this out in a test case using only openjpa and I did not see the
>>> same
>>> behavior. I did not try it using any other database, but I don't
>>> think this
>>> is a problem in that part of the code. I did look at the sql
>>> generated, and
>>> it looks like all of the columns are being selected. One other
>>> thing I did,
>>> I downloaded the openejb source, and started looking through it, but
>>> I'm not
>>> familiar with the code at all and was hoping the problem would manifest
>>> itself in my code somewhere.... Thanks for your help, please let me
>>> know
>>> when you find the problem.
>>>
>>> -chris
>>>
>>>
>>> Jonathan Gallimore-2 wrote:
>>>
>>>> I've managed to reproduce the issue with your code (many thanks for
>>>> that!). I'm not sure why its happening, your code looks ok to me,
>>>> so I'm going to dig deeper to try and figure out what's going on.
>>>>
>>>> Cheers
>>>>
>>>> Jon
>>>>
>>>>
>>>> coloradoflyer wrote:
>>>>
>>>>> Hi Jon/all,
>>>>>
>>>>> I attached a jar with the test case. Basically, there are 5
>>>>> source files
>>>>> in
>>>>> here and a sql script to create the entities.
>>>>> The interface for the stateless session bean, the concrete class
>>>>> for it.
>>>>> The 2 Entites, and the Test case. Its pretty small.
>>>>>
>>>>> If you take a look at the test case, if it passes, that in itself
>>>>> displays
>>>>> the problem. The test case is TestAudioServices, and the line that
>>>>> **should** fail is line 40, it looks for null for the name of the
>>>>> status
>>>>> (which should never be null). The proof that this case displays the
>>>>> problem, is on line 43, basically line 42 reloads the entity by
>>>>> its id,
>>>>> and
>>>>> then checks to see if the status now is not null, one of those 2
>>>>> lines
>>>>> (41
>>>>> or 43) should fail.
>>>>>
>>>>> These are the lines in question:
>>>>> file = stateless.update(file);
>>>>> assertNull(file.getAudioFileStatus().getName());
>>>>> file = stateless.findById(file.getId());
>>>>> assertNotNull(file.getAudioFileStatus().getName());
>>>>>
>>>>> Thanks for looking into this, I keep thinking I'm going to find
>>>>> something
>>>>> wrong in my code, but I'm not seeing it so far, and its relatively
>>>>> trivial
>>>>> now.
>>>>> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
>>>>> -chris
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: openejb3.1 merge
Posted by David Blevins <da...@visi.com>.
Haven't had a chance to look at the issue, but it's starting to sound
like a detach. Per spec, when the transaction ends, all objects
pulled from a TRANSACTION scoped PersistenceContext are detached and
no more data will be read into them. This can lead to strange state
as most vendors do lazy loading and therefore any fields not loaded
after the detach will stay unset.
Try switching your Stateless bean to a Stateful and changing your
PersistenceContextType.TRANSACTION to PersistenceContextType.EXTENDED.
-David
On Mar 16, 2009, at 2:00 PM, Jonathan Gallimore wrote:
> Yes, you did mention that - should help narrow down the problem ;-)
>
> I tried your code with both HSQLDB and Postgresql with the same
> result on both. org.apache.openejb.persistence.JtaEntityManager is
> the class that gets injected into _entityManager in your Session
> bean, and this is a wrapper around the OpenJPA entity manager. I'm
> wondering whether we're setting something up differently to how
> you're using OpenJPA on its own. I'm currently checking out OpenJPA
> to delve into this further.
>
> Cheers
>
> Jon
>
>
> coloradoflyer wrote:
>> Hi Jon,
>>
>> Thanks for your help. I'm not sure if I mentioned this or not, but
>> I did
>> try this out in a test case using only openjpa and I did not see
>> the same
>> behavior. I did not try it using any other database, but I don't
>> think this
>> is a problem in that part of the code. I did look at the sql
>> generated, and
>> it looks like all of the columns are being selected. One other
>> thing I did,
>> I downloaded the openejb source, and started looking through it,
>> but I'm not
>> familiar with the code at all and was hoping the problem would
>> manifest
>> itself in my code somewhere.... Thanks for your help, please let
>> me know
>> when you find the problem.
>>
>> -chris
>>
>>
>> Jonathan Gallimore-2 wrote:
>>
>>> I've managed to reproduce the issue with your code (many thanks
>>> for that!). I'm not sure why its happening, your code looks ok to
>>> me, so I'm going to dig deeper to try and figure out what's going
>>> on.
>>>
>>> Cheers
>>>
>>> Jon
>>>
>>>
>>> coloradoflyer wrote:
>>>
>>>> Hi Jon/all,
>>>>
>>>> I attached a jar with the test case. Basically, there are 5
>>>> source files
>>>> in
>>>> here and a sql script to create the entities.
>>>> The interface for the stateless session bean, the concrete class
>>>> for it.
>>>> The 2 Entites, and the Test case. Its pretty small.
>>>>
>>>> If you take a look at the test case, if it passes, that in itself
>>>> displays
>>>> the problem. The test case is TestAudioServices, and the line that
>>>> **should** fail is line 40, it looks for null for the name of the
>>>> status
>>>> (which should never be null). The proof that this case displays
>>>> the
>>>> problem, is on line 43, basically line 42 reloads the entity by
>>>> its id,
>>>> and
>>>> then checks to see if the status now is not null, one of those 2
>>>> lines
>>>> (41
>>>> or 43) should fail.
>>>>
>>>> These are the lines in question:
>>>> file = stateless.update(file);
>>>> assertNull(file.getAudioFileStatus().getName());
>>>> file = stateless.findById(file.getId());
>>>> assertNotNull(file.getAudioFileStatus().getName());
>>>>
>>>> Thanks for looking into this, I keep thinking I'm going to find
>>>> something
>>>> wrong in my code, but I'm not seeing it so far, and its relatively
>>>> trivial
>>>> now.
>>>> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar -
>>>> chris
>>>>
>>>
>>>
>>
>>
>
Re: openejb3.1 merge
Posted by Jonathan Gallimore <jo...@gmail.com>.
Yes, you did mention that - should help narrow down the problem ;-)
I tried your code with both HSQLDB and Postgresql with the same result
on both. org.apache.openejb.persistence.JtaEntityManager is the class
that gets injected into _entityManager in your Session bean, and this is
a wrapper around the OpenJPA entity manager. I'm wondering whether we're
setting something up differently to how you're using OpenJPA on its own.
I'm currently checking out OpenJPA to delve into this further.
Cheers
Jon
coloradoflyer wrote:
> Hi Jon,
>
> Thanks for your help. I'm not sure if I mentioned this or not, but I did
> try this out in a test case using only openjpa and I did not see the same
> behavior. I did not try it using any other database, but I don't think this
> is a problem in that part of the code. I did look at the sql generated, and
> it looks like all of the columns are being selected. One other thing I did,
> I downloaded the openejb source, and started looking through it, but I'm not
> familiar with the code at all and was hoping the problem would manifest
> itself in my code somewhere.... Thanks for your help, please let me know
> when you find the problem.
>
> -chris
>
>
> Jonathan Gallimore-2 wrote:
>
>> I've managed to reproduce the issue with your code (many thanks for
>> that!). I'm not sure why its happening, your code looks ok to me, so I'm
>> going to dig deeper to try and figure out what's going on.
>>
>> Cheers
>>
>> Jon
>>
>>
>> coloradoflyer wrote:
>>
>>> Hi Jon/all,
>>>
>>> I attached a jar with the test case. Basically, there are 5 source files
>>> in
>>> here and a sql script to create the entities.
>>> The interface for the stateless session bean, the concrete class for it.
>>> The 2 Entites, and the Test case. Its pretty small.
>>>
>>> If you take a look at the test case, if it passes, that in itself
>>> displays
>>> the problem. The test case is TestAudioServices, and the line that
>>> **should** fail is line 40, it looks for null for the name of the status
>>> (which should never be null). The proof that this case displays the
>>> problem, is on line 43, basically line 42 reloads the entity by its id,
>>> and
>>> then checks to see if the status now is not null, one of those 2 lines
>>> (41
>>> or 43) should fail.
>>>
>>> These are the lines in question:
>>> file = stateless.update(file);
>>>
>>> assertNull(file.getAudioFileStatus().getName());
>>>
>>> file = stateless.findById(file.getId());
>>> assertNotNull(file.getAudioFileStatus().getName());
>>>
>>> Thanks for looking into this, I keep thinking I'm going to find something
>>> wrong in my code, but I'm not seeing it so far, and its relatively
>>> trivial
>>> now.
>>> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
>>> -chris
>>>
>>>
>>
>>
>
>
Re: openejb3.1 merge
Posted by coloradoflyer <op...@parallelsw.com>.
Hi Jon,
Thanks for your help. I'm not sure if I mentioned this or not, but I did
try this out in a test case using only openjpa and I did not see the same
behavior. I did not try it using any other database, but I don't think this
is a problem in that part of the code. I did look at the sql generated, and
it looks like all of the columns are being selected. One other thing I did,
I downloaded the openejb source, and started looking through it, but I'm not
familiar with the code at all and was hoping the problem would manifest
itself in my code somewhere.... Thanks for your help, please let me know
when you find the problem.
-chris
Jonathan Gallimore-2 wrote:
>
> I've managed to reproduce the issue with your code (many thanks for
> that!). I'm not sure why its happening, your code looks ok to me, so I'm
> going to dig deeper to try and figure out what's going on.
>
> Cheers
>
> Jon
>
>
> coloradoflyer wrote:
>> Hi Jon/all,
>>
>> I attached a jar with the test case. Basically, there are 5 source files
>> in
>> here and a sql script to create the entities.
>> The interface for the stateless session bean, the concrete class for it.
>> The 2 Entites, and the Test case. Its pretty small.
>>
>> If you take a look at the test case, if it passes, that in itself
>> displays
>> the problem. The test case is TestAudioServices, and the line that
>> **should** fail is line 40, it looks for null for the name of the status
>> (which should never be null). The proof that this case displays the
>> problem, is on line 43, basically line 42 reloads the entity by its id,
>> and
>> then checks to see if the status now is not null, one of those 2 lines
>> (41
>> or 43) should fail.
>>
>> These are the lines in question:
>> file = stateless.update(file);
>>
>> assertNull(file.getAudioFileStatus().getName());
>>
>> file = stateless.findById(file.getId());
>> assertNotNull(file.getAudioFileStatus().getName());
>>
>> Thanks for looking into this, I keep thinking I'm going to find something
>> wrong in my code, but I'm not seeing it so far, and its relatively
>> trivial
>> now.
>> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
>> -chris
>>
>
>
>
--
View this message in context: http://www.nabble.com/openejb3.1-merge-tp22469332p22545574.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: openejb3.1 merge
Posted by Jonathan Gallimore <jo...@gmail.com>.
I've managed to reproduce the issue with your code (many thanks for
that!). I'm not sure why its happening, your code looks ok to me, so I'm
going to dig deeper to try and figure out what's going on.
Cheers
Jon
coloradoflyer wrote:
> Hi Jon/all,
>
> I attached a jar with the test case. Basically, there are 5 source files in
> here and a sql script to create the entities.
> The interface for the stateless session bean, the concrete class for it.
> The 2 Entites, and the Test case. Its pretty small.
>
> If you take a look at the test case, if it passes, that in itself displays
> the problem. The test case is TestAudioServices, and the line that
> **should** fail is line 40, it looks for null for the name of the status
> (which should never be null). The proof that this case displays the
> problem, is on line 43, basically line 42 reloads the entity by its id, and
> then checks to see if the status now is not null, one of those 2 lines (41
> or 43) should fail.
>
> These are the lines in question:
> file = stateless.update(file);
>
> assertNull(file.getAudioFileStatus().getName());
>
> file = stateless.findById(file.getId());
> assertNotNull(file.getAudioFileStatus().getName());
>
> Thanks for looking into this, I keep thinking I'm going to find something
> wrong in my code, but I'm not seeing it so far, and its relatively trivial
> now.
> http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
> -chris
>
Re: openejb3.1 merge
Posted by coloradoflyer <op...@parallelsw.com>.
Hi Jon/all,
I attached a jar with the test case. Basically, there are 5 source files in
here and a sql script to create the entities.
The interface for the stateless session bean, the concrete class for it.
The 2 Entites, and the Test case. Its pretty small.
If you take a look at the test case, if it passes, that in itself displays
the problem. The test case is TestAudioServices, and the line that
**should** fail is line 40, it looks for null for the name of the status
(which should never be null). The proof that this case displays the
problem, is on line 43, basically line 42 reloads the entity by its id, and
then checks to see if the status now is not null, one of those 2 lines (41
or 43) should fail.
These are the lines in question:
file = stateless.update(file);
assertNull(file.getAudioFileStatus().getName());
file = stateless.findById(file.getId());
assertNotNull(file.getAudioFileStatus().getName());
Thanks for looking into this, I keep thinking I'm going to find something
wrong in my code, but I'm not seeing it so far, and its relatively trivial
now.
http://www.nabble.com/file/p22509703/testerror.jar testerror.jar
-chris
Jonathan Gallimore-2 wrote:
>
> Nothing obvious immediately springs to my mind as to why this might
> happen. Would you be able to provide us with a test case that produces
> this problem so we could troubleshoot it?
>
> Regards
>
> Jon
>
>
> coloradoflyer wrote:
>> Hi all,
>>
>> I wrote a small app to look at openejb and am having an issue with one of
>> the relationships.
>>
>> Before posting too much code I wanted to see if anything is obviously
>> wrong.
>> The application has about 5 tables, I'm creating one row and building a
>> OneToMany association to another pre-existing entity, this all works
>> without
>> issue. The next step in my test case was to update the OneToMany to
>> another
>> pre-existing entity. All of the fields are already populated and I'm
>> invoking the setter on the entity. Once this is done, I invoked the
>> merge
>> method on the Injected entityManager. The object returned from this is
>> in
>> tact, and has the association, but one of the fields in the associated
>> object is set to null.
>>
>> I'm working in OpenJPA 1.1, OpenEJB3.1, database is Postgres.
>> The code is inside a local Stateless session bean method.
>>
>> The foreign key association for the onetomany is updated, and if I invoke
>> the finder to reload the object, it all loads properly, and the null
>> field
>> is populated properly.
>>
>> finally, in order to ensure this was an openejb problem and not something
>> specific to openjpa, I broke the code out of the stateless session, and
>> ran
>> the same code with the transaction management in place without openejb.
>> Basically, the entity ended up with the proper field value after the
>> merge.
>>
>> thanks for any info/help.
>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/openejb3.1-merge-tp22469332p22509703.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: openejb3.1 merge
Posted by Jonathan Gallimore <jo...@gmail.com>.
Nothing obvious immediately springs to my mind as to why this might
happen. Would you be able to provide us with a test case that produces
this problem so we could troubleshoot it?
Regards
Jon
coloradoflyer wrote:
> Hi all,
>
> I wrote a small app to look at openejb and am having an issue with one of
> the relationships.
>
> Before posting too much code I wanted to see if anything is obviously wrong.
> The application has about 5 tables, I'm creating one row and building a
> OneToMany association to another pre-existing entity, this all works without
> issue. The next step in my test case was to update the OneToMany to another
> pre-existing entity. All of the fields are already populated and I'm
> invoking the setter on the entity. Once this is done, I invoked the merge
> method on the Injected entityManager. The object returned from this is in
> tact, and has the association, but one of the fields in the associated
> object is set to null.
>
> I'm working in OpenJPA 1.1, OpenEJB3.1, database is Postgres.
> The code is inside a local Stateless session bean method.
>
> The foreign key association for the onetomany is updated, and if I invoke
> the finder to reload the object, it all loads properly, and the null field
> is populated properly.
>
> finally, in order to ensure this was an openejb problem and not something
> specific to openjpa, I broke the code out of the stateless session, and ran
> the same code with the transaction management in place without openejb.
> Basically, the entity ended up with the proper field value after the merge.
>
> thanks for any info/help.
>
>
>