[Yanel-dev] Concurrent Read Write Locks

[basZero]

Hi Michael,
a little comment on your URLs.

the Jenkov link says that we should use the java.util.concurrent package
instead of implementing our own.
I read the probably most well known book about concurrency in Java, written
by "the father of concurrency" Brian Goetz:
http://www.javaconcurrencyinpractice.com/

The book is very very good, and I remember one sentence which he outlined
again and again:
concurrency code written from scratch will always have bug, even mature
frameworks will still have bugs, just because the concurrency is such a
complex technical topic.

So, I just want to say: be careful when bringing something like this into
Yanel. Maybe start small before designing a huge synchronization facade.

Cheers
Balz

On Wed, May 30, 2012 at 2:55 PM, basZero <baszero at gmail.com> wrote:

> Hi Michael,
> i can have a look at my mails and I'll send them to you again.
>
> Your suggested behaviour looks good to me, although the waiting write for
> all active reads is probably not that easy to implement.
>
> Another very important aspect is to consider the correct scope:
> - global files (e.g. a data file that can be modified by any user) must
> use a LOCK object of global scope (that's easy, it's a public static final
> Object GLOBAL_LOCK = new Object();)
>
> - user specific files (e.g. user profile extension), files that are
> modified by the same user, always, such modifications do not need to be
> synchronized globally, but within the session. For Zwischengas I have
> implemented a nice helper class which uses an object stored in the user's
> session which gets used for session-scoped synchronization.
>
> If you are planning to draft a design for this, I will spend some time to
> review it, if you want. Or we can have another tech-lunch together :)
>
> Cheers
> Balz
>
> On Wed, May 30, 2012 at 2:43 PM, Michael Wechner <
> michael.wechner at wyona.com> wrote:
>
>> Hi Balz
>>
>> I remember that you once suggested how we should improve concurrent
>> read/write operations, but
>> unfortunately I cannot find your email anymore.
>>
>> I think the behaviour should be as follows:
>>
>> - Concurrent read operations do not block each other
>> - If a thread wants to write, then it first needs to wait until all
>> current read operations have finished
>> - A write operation blocks new read requests until the writing has
>> finished
>>
>> It seems to me the following articles describe the solution quite nicely
>>
>> http://www.javalobby.org/java/**forums/t45090.html<http://www.javalobby.org/java/forums/t45090.html>
>> http://tutorials.jenkov.com/**java-concurrency/read-write-**locks.html<http://tutorials.jenkov.com/java-concurrency/read-write-locks.html>
>>
>> WDYT?
>>
>> As an alternative we could also implement the functionality, that if a
>> repository has revisions enabled and
>> if revisions are actually being created, that the read process always
>> accesses the most recent revision, which
>> would normally be the same as accessing the actuall node. Of course the
>> creation of the revision would also have to be locked.
>>
>> Thanks
>>
>> Michael
>> --
>> Yanel-development mailing list Yanel-development at wyona.com
>> http://lists.wyona.org/cgi-**bin/mailman/listinfo/yanel-**development<http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20120530/92a31fc4/attachment.html>