[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openejb-user
Subject:    Re: openejb3.1 merge
From:       David Blevins <david.blevins () visi ! com>
Date:       2009-04-01 0:41:09
Message-ID: 087983CD-E8BA-4A33-9A97-30E1E9BB2239 () visi ! com
[Download RAW message or body]


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.
>
>

[prev in list] [next in list] [prev in thread] [next in thread]