cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <>
Subject Re: Flowscript, CForms and one writer, many readers
Date Tue, 06 Jul 2004 08:58:21 GMT
Il giorno 06/lug/04, alle 09:24, Colin Paul Adams ha scritto:

> I have a simple diary application.
> At present, it reads the events data from an XML file.
> Using CForms and the XML file binding, anyone can update the events
> data.
> Of course, this suffers from the usual problems if two people try to
> update the data at the same time.
> So I think I need to use a database and transactions to solve this.

No, you don't. What you're trying to do is called "pessimistic locking" 
and unfortunately it is very hard to implement in a web application. 
Imagine a user selects the data for updating, therefore locking it. 
Then the user is presented with a form for editing. You have a pending 
transaction and one or more locked records. What happens if the user 
never submits the form, but just closes the browser, walks away or 
surfs to some other website? The transaction is never closed and the 
records are locked forever (unless you implement some kind of timeout).

A possible solution is the so-called "optimistic locking" strategy. 
First user select the data but does not lock it. When the form is 
submitted, before applying the updates the system checks if the data 
have been modified since the select and in this case it either refuses 
to update or, if possible, merges the updates.

This is how CVS works, for instance, and the easiest way to implement 
it is via a "version" attribute on the data. Whenever an update is 
performed, the version number is incremented. If I retrieved data at 
version "1", before committing my updates the system has to verify that 
the data in storage is still at version "1". If it is, it commits and 
increments the version number to "2". If it isn't, it either attempts a 
merge or fails. If it fails, it can present the user with the latest 
version of stored data and ask him to apply his changes again.

Optimistic locking increases concurrency at the expense of the 
occasional conflict. You're being optimistic in that you assume the 
conflicts are rare. Pessimistic locking decreases concurrency (some 
users may be forced to wait) but guarantees that you won't get any 
conflict. Unfortunately, as I wrote above, implementing pessimistic 
locking in a web aplication is hard. Since your data is XML, it might 
be possible to easily implement a merging algorithm, so that even in 
the event of conflicts, most of them might be solved without the user 
knowing about them. In this case, I'd opt for the optimistic locking 

Now, you don't need an RDBMS to implement an optimistic locking 
strategy. You just have to add a "version" attribute to your records, 
the logic to manage it and make sure that only one thread at a time is 
allowed to write the data.

> Reading around, it seems binding to a bean using JDO is a decent way
> to go.

Don't know about JDO, but Hibernate supports automatic versioning 

> But I can't find a way to store such a singleton object in
> flowscript. There is a request object, a saession object, but no
> application object (like ASP has).
> What's the way to do this in flowscript?

If you have a Java class implementing the singleton pattern, it's 
supposed to have a method like:

   public static MySingleton getInsance();

which returns the only existing instance of the class. Then you just 
have to call it from your flowscript code.


Ugo Cei -

View raw message