Hi, On 26.02.2010 19:11, Jukka Zitting wrote: > Hi, > > On Fri, Feb 26, 2010 at 6:36 PM, Felix Meschberger <[email protected]> wrote: >> Consider two threads T1 and T2 each modifying data from the same session: >> >> T1 makes some modifications >> T2 makes some modifications >> T1 saves the session (incl. both T1's and T2's modifs) >> T2 makes some more modifications >> T2 decides to rollback >> >> At the end the content is inconsistent from the POV of T2 because some >> modifications have been persistent and some haven't. > > This has nothing to do with synchronizing session access. If T2 wants > a separate transient space, it should use a separate session. > > All we're trying to achieve here is ensure internal consistency even > when clients do something like the above (for whatever reason, > intentional or not).
To what avail ? Quoting Thomas Müller: > In some cases, incorrect usage leads to data corruption. I > believe data corrupt is not acceptable, even if the user made a > mistake. Now, you say, actual data consistency is not the goal, but internal concistency is. All end-users (not the ones doing the coding) really care about is data consistency. They don't care for a distinciton of internal and external consistency. Plus: This is *not* about users like my grand-mother who never touched a computer in her life. This is about programmers who must adhere to a programming model and to API contracts. If they do not, it is their fault and they have to live with the consequences of their doing the wrong thing. If a Session can do better when used concurrently, fine. But not with synchronizing all methods. E.g.: How about taking note of the current thread when the transient space is first used by a thread making modifications. As soon as another thread is trying to use the same transient space, an exception might be thrown. This way the transient space is "owned" by a session until refresh or commit. This is IMHO super-simple, fast and safe. The only thing to care about -- and find a solution -- is, that the Session might effectively become read-only if a thread starts modifying content and then abandons without commit or refresh. Regards Felix
