those DTOs is not fun, but pick your posion.
|-Original Message-
|From: Phil Warrick [mailto:[EMAIL PROTECTED]
|Sent: Thursday, February 27, 2003 9:33 AM
|To: OJB Users List
|Subject: Re: long transactions
|
|
|Hi again,
|
|One reason I
long transaction support was just a superfluous benefit.
|-Original Message-
|From: Mahler Thomas [mailto:[EMAIL PROTECTED]
|Sent: Thursday, February 27, 2003 9:50 AM
|To: 'OJB Users List'
|Subject: RE: long transactions
|
|
|Hi all,
|
|
| I have
Hi again (again),
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
Hi again
snip OL stuff
Right, write conflicts are detected with OL. But will there be an
efficient merge of the updated graph?
No.
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
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
: Re: long transactions
|
|
| 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
The example I gave was a Customer and a Product. The Customer has a
collection of Products, the relation of which is maintained in say a
CUSTOMER_PRODUCT table. Because it is non-decomposed, I do not create a
CustomerProduct class. Now in client code, I do:
Customer customer = // lookup
