Re: long transactions

[Phil Warrick]

Hi,

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.
Can you expand on the PB approach a little?  How is it that no merge is 
necessary with optimistic locking?

Thanks,

Phil

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]