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.
