Re: Gdata Concurrency

[Otis Gospodnetic <ot...@yahoo.com>]

Hi Simon,

I think you should leave the concurrency/transaction logic up to the storage component implementation.

Otis
P.S.
World Cup...sorry.... I feel your pain. ;)
 
----- Original Message ----
From: Simon Willnauer <si...@googlemail.com>
To: java-dev@lucene.apache.org
Sent: Saturday, June 24, 2006 2:52:58 PM
Subject: Gdata Concurrency

Hello everyone,
next round for Germany in the fifa world cup and next round in Summer
of Code Program.
A little overview for you guys... The Gdata Server does basically
serve  RSS / Atom feeds and  enables users to insert , update and
delete entries if they are authenticated. To ensure lost updates and
overwrite already updated entries
Quote from code.google.com: "Sometimes it is important to ensure that
multiple clients don't inadvertently overwrite one another's changes.
This is most easily accomplished by ensuring that the current version
of an entry that a client is modifying is the same as the version that
the client is basing its modifications on. If a second client makes an
update before the first client does, then the first client's update is
denied, because the first client is no longer basing its modifications
on the latest version."

First of all a design decision has to be done. The "concurrency
component" could either be located as a separate part of the server
somewhere in the logic layer or as a part of the storage component. as
the storage comp. is the last component in the modification life cycle
 and has to deal with distributed systems anyway.
The storage component provides a public interface to enable developers
to develop their own storage and usually has a "transactional state"
and can provide the required isolation level.

Another way e.g. a new "standalone" concurrency system requires
communication with other servers inside a farm. Which could end up in
a lot of communication via the servers. On the other hand new storage
components don't have to reimplement the concurrency.

waiting for your suggestions

regards simon

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org