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 strategy.
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 out-of-the-box.
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
-- Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
