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]

Reply via email to