views:

38

answers:

2

This question is best described by a picture I think. I hope someone can help me. Thanksalt text

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
so your theory is it's the first level cache that's returning the old object?
tieTYT
@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
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ý