jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [jr3] Synchronized sessions
Date Sat, 27 Feb 2010 07:07:17 GMT

On 26.02.2010 19:11, Jukka Zitting wrote:
> Hi,
> On Fri, Feb 26, 2010 at 6:36 PM, Felix Meschberger <fmeschbe@gmail.com> 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.


View raw message