This question is best described by a picture I think. I hope someone can help me. Thanks
views:
38answers:
2
A:
I'm not sure you gave all the context but if (1) and (2) are running inside the same transaction, I'd say that the entity is in the L1 cache, that's what the question suggests, and that changes made in "update row" are not visible because they were done inside another persistence context (a nested transaction), hence the need to refresh
the state of the instance from the database.
Pascal Thivent
2010-05-01 01:12:11
so your theory is it's the first level cache that's returning the old object?
tieTYT
2010-05-03 18:27:22
@tieTYT Yes and I'm pretty sure it's more than a theory :) (by the way, this question seems to be provider agnostic and there is no L2 cache in JPA 1.0).
Pascal Thivent
2010-05-03 20:46:54
A:
I agree with Pascal, if the two calls from EJB1 are in the same transaction then it's clear that (2) cannot see the changes performed by (1) because they were performed in another transaction (assuming a reasonable transaction isolation level, of course)
1. EJB1 transaction (TX1) starts
2. EJB1.(1) called
3. EJB2.update row started => TX1 is suspended and
a new transaction, TX2, is started
4. The update is performed
5. TX2 commits
6. TX1 is resumed - it can't see changes by TX2 because it's isolated from
changes performed by other transactions during its "life"
7. EJB1.(2) invokes EJB2.find row withing the context of TX1 => can't see TX2's changes
8. TX1 commits
Jakub Holý
2010-05-03 21:57:05