When recording pending changes to an Item in the Session at least two approaches are possible. Which approach is taken is up to the implementation.
Copy-on-Read: When an Item object is acquired, its state in persistent storage is copied to transient storage associated with the Session. Any subsequent changes are applied to the transient state object. Upon save, the transient state object is copied back to persistent storage and removed from transient storage. In such an implementation, when an Item is retrieved through a particular Session, any changes made to the persistent state of that item by another Session will not be visible to the first Session until a refresh and reacquisition of the item in question. Under this system, conflicts with persistent state will only be detected upon save, meaning that InvalidItemStateException will only be thrown on save, not earlier. The copy-on-read approach also has some repercussions in the context of transactions (in those implementations that support this feature). See 8.1.4 Single Session Across Multiple Transactions.
Copy-on-Write: An alternative approach is not to immediately copy the state of a newly acquired Item object to transient storage, but rather to only copy the state when a change is made to that state. In this case, as long as no changes are made to an Item object, its state always reflects the current state in persistent storage and thus any changes in that persistent state made by other sessions are immediately visible through the methods of that Item. If, on the other hand, a change is made to the Item state by this Session then the item state is copied from persistent storage to transient storage and the change is applied to that copy. From this point until a refresh or save, changes made to the persistent item will not be visible through the Item object. Note that in copy-on-write implementations a refresh(true) (a refresh that does not discard pending changes) will, by definition, have no effect.
This specification does not prescribe either of these approaches. Implementations are free to use either one (or indeed any other that may be suitable) as long as the minimal requirement is met of never allowing two Item objects acquired through the same Session to reflect conflicting state information.