Hi Okwui, yes, as David says. Your use case falls into my "good news - it just works" statement.
Dan On 22 July 2013 23:01, David Tildesley <[email protected]> wrote: > Hi Okwui, > > This is trivial - it's business rule driven (encapsulated in (dom) > business object method code) and can be done in the normal ISIS transaction > lifecycle. Nothing special. > > Regards, > David. > > > > > ________________________________ > From: Okwui <[email protected]> > To: "[email protected]" <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Monday, 22 July 2013 8:16 PM > Subject: Re: Transaction Handling > > > Consider this use case: > I have an inventory transaction that transfers goods from one warehouse to > another. I need to increase inventory in receiving location and decrease > inventory in issuing location. Each location has a stock ledger entity. I > want the increase in receiving stock ledger entity quantityAtHand and the > decrease in the issuing stock ledger entity quantityAtHand to be handled as > one transaction ie succeed or fail together. And this happens > programmatically as part of the lifecycle of the transaction entity. > > Sent from my iPad > > On Jul 20, 2013, at 10:07 PM, David Tildesley <[email protected]> wrote: > > > Hi O. would be easier to answer your question if you described your use > case. If it is just single database persistence I would question why you > would want to do this in the first place. But anyway, I don't see any > reason why you couldn't detach your business objects using jdo detachable, > work on them, and when you are ready to save, call your custom operation to > reattach and persist (the viewer will do the transaction).. > > > > But I'm not a developer, I'm an architect so you will need some further > advice on this. > > > > David. > > > > Sent from Yahoo! Mail on Android > > >
