Hi David,
Yes, the ODMG and OTM layer provide support for long transactions.
They both provide means to transfer Objects back to transactions (aka
swizzling).
Thomas
David Hooker wrote:
Does OJB support "long transactions"?
-
Message-
> From: Phil Warrick [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 27, 2003 8:54 PM
> To: OJB Users List
> Subject: Re: long transactions
>
>
> Hi again,
>
> >> Right, write conflicts are detected with OL. But will there be an
> 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 = // l
Hi again,
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 update on only
Users List
|Subject: 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 serve
> > 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 inst
Hi again
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 update on only
Hi again (again),
Hi again,
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
l Message-
> >>|From: Phil Warrick [mailto:[EMAIL PROTECTED]
> >>|Sent: Thursday, February 27, 2003 9:33 AM
> >>|To: OJB Users List
> >>|Subject: Re: long transactions
> >>|
> >>|
> >>|Hi agai
utral
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,
|
OJB Users List
|Subject: Re: long transactions
|
|
|Hi again,
|
|One reason I ask is that long transactions seem to imply
|_stateful_
|Session beans + OJB, and I haven't seen much discussion or
|examples
|relating to this combination (although there are lots
version labels to detect write conflicts.
cheers,
Thomas
> Of course writing all 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:
our 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 ask is that long transactions see
Hi again,
One reason I ask is that long transactions seem to imply _stateful_
Session beans + OJB, and I haven't seen much discussion or examples
relating to this combination (although there are lots of _stateless_
Session bean + OJB discussion/examples).
My core data is essentially a tree, so
14 matches
Mail list logo
