This article states that if we use 2 transactions one for getting first data and afterwords to get the lazy fields, we won't run into any problems since the session is reused and the session itself guarantees repeatable read. But this doesn't seem possible, session look to satisfy repeatable read requirements only when it comes to data that is already in its cache. But what if the object along with its underlying lazy OTO was removed? I understand that for collection it might not cause problems, it will simply return empty collection. But OTO... getChildField() will return proxy (since OTO configured with restricted=true), but it shouldn't do that since everything is null already. Does anyone have an answer?
The article says what you're saying: loading objects on demand, across several transactions, is not reliable:
The solution for this issue is of course proper unit of work demarcation and design, supported by possibly an interception technique as shown in the pattern here, and/or the correct fetch technique so that all required information for a particular unit of work can be retrieved with minimum impact, best performance, and scalability.