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
