Actually the problem we were trying to get around wasn't so much the long
transactions (as Castor does have support for that), but the performance hit
of serialization and de-serialization and network communication of
large/deep object graphs inherent in EJB environments. The platform-neutral
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 just started converting our system to use OJB instead
|> of Castor, so I
|> cannot speak to the PB v. ODMG approach. However, our
|> perferred approach
|> has been to implement long transactions using what are named
|> DataTransferObjects. Especially if you are using a session
|> bean layer, the
|> DTOs can be looked at as snapshots of your domain model
|> highly tuned for a
|> particular client for a particular use-case.
|
|That's the default approach
|
|> During "save"
|> or the long
|> transaction, simply lock the appropriate domain object(s) and
|> merge in the
|> data from the DTO.
|
|this process is called swizzling. We have implemented it
|in the new OTM
|layer. But for ODMG you have to do the merging on your own.
|With the PB api you can ignore swizzling as you can use
|optimistic locking
|with timespamp or 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: 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 of
|> |_stateless_
|> |Session bean + OJB discussion/examples).
|> |
|> |My core data is essentially a tree, so updates (performed
|> |on a remove
|> |client) implicate a large graph of persistent objects.
|> |
|> |Does anyone have ideas/experiences to share?
|Pitfalls to avoid?
|> |
|> |Thanks,
|> |
|> |Phil
|> |
|> |Phil Warrick wrote:
|> |> Hi Thomas,
|> |>
|> |> A while ago, you mentioned that although long
|> |transactions are not
|> |> currently supported, there are a few possible approaches:
|> |>
|> |> >If you want to use the ODMG in your SessionBean
|> |scenario you have to
|> |> > implement your own simple long transaction mechanism.
|> |> > (In the OTM package we will have such a feature
|> implemented.)
|> |> > On the other hand ODMG is not the most natural fit
|> |for such a scenario.
|> |> > I recommemd to use the PersistenceBroker API
|for such cases!
|> |>
|> |> Can you outline what the ODMG long transaction would
|> |look like in a
|> |> SessionBean scenario? And how PB is perhaps a better
|> |approach? What
|> |> will the OTM approach look like?
|> |>
|> |> Over the last few months, I have been trying several
|> avenues for
|> |> modifying persistent objects on remote clients and then
|> |updating them on
|> |> the server, and I still haven't arrived at a
|> |satisfactory approach.
|> |>
|> |> Any thoughts and experiences in this area would be most
|> |appreciated.
|> |>
|> |> Thanks,
|> |>
|> |> Phil
|> |
|> |
|> |
|> |-----------------------------------------------------------
|> |----------
|> |To unsubscribe, e-mail: [EMAIL PROTECTED]
|> |For additional commands, e-mail: [EMAIL PROTECTED]
|> |
|>
|>
|-----------------------------------------------------------
|----------
|> To unsubscribe, e-mail: [EMAIL PROTECTED]
|> For additional commands, e-mail: [EMAIL PROTECTED]
|>
|>
|
|
|-----------------------------------------------------------
|----------
|To unsubscribe, e-mail: [EMAIL PROTECTED]
|For additional commands, e-mail: [EMAIL PROTECTED]
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
