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 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 matches the version entry in the database row. In our case we will know that some other process updated the object if the version cloumn is now greater 15. The server will then signal a problem to the client. If the version still matches, the object is updated to the db and the version field is incremented, to inform other processes about the update. Thomas > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
