Hi again,
<snip>
With the PB api you can ignore swizzling as you can use
optimistic locking
with timespamp or version labels to detect write conflicts.
Can you expand on the PB approach a little? How is it that no merge is necessary with optimistic locking?
With OL you have a version column for each row.
Say you load an object with version=15.
you send it to the client.
The client works on it and posts the modified object back to the server.
the server then update the database. With OL it checks if the version field in the instance still matches the
version entry in the database row.
In our case we will know that some other process updated the object if the
version cloumn is now greater 15.
The server will then signal a problem to the client.
If the version still matches, the object is updated to the db and the version field is incremented, to inform other processes about the update.
Right, write conflicts are detected with OL. But will there be an efficient merge of the updated graph? Say only one of the graph's n objects was modified. Is OJB's use of its cache going to compare the before/after status of each graph object and perform a db update on only the one truly changed object?
Are we close to being a FAQ item?
Thanks a lot,
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
