You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Okwui <ok...@gmail.com> on 2013/07/20 03:14:57 UTC
Re: Transaction Handling
I am trying to implement a business system. I want to be able to make a set of changes to different entities which will either succeed or fail together. Is there a way to manage transactions?
Re: Transaction Handling
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Please do. Not quite sure why you are sceptical. But let us know if you
hit any issues.
On 23 July 2013 07:17, james agada <ok...@gmail.com> wrote:
> Really? I'll go on and see what happens.
>
> Sent from my iPhone
>
> On Jul 22, 2013, at 11:04 PM, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
>
> > 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 <da...@yahoo.co.nz> 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 <ok...@gmail.com>
> >> To: "users@isis.apache.org" <us...@isis.apache.org>
> >> Cc: "users@isis.apache.org" <us...@isis.apache.org>
> >> 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 <da...@yahoo.co.nz>
> 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
> >>
>
Re: Transaction Handling
Posted by james agada <ok...@gmail.com>.
Really? I'll go on and see what happens.
Sent from my iPhone
On Jul 22, 2013, at 11:04 PM, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> 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 <da...@yahoo.co.nz> 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 <ok...@gmail.com>
>> To: "users@isis.apache.org" <us...@isis.apache.org>
>> Cc: "users@isis.apache.org" <us...@isis.apache.org>
>> 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 <da...@yahoo.co.nz> 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
>>
Re: Transaction Handling
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
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 <da...@yahoo.co.nz> 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 <ok...@gmail.com>
> To: "users@isis.apache.org" <us...@isis.apache.org>
> Cc: "users@isis.apache.org" <us...@isis.apache.org>
> 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 <da...@yahoo.co.nz> 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
> >
>
Re: Transaction Handling
Posted by David Tildesley <da...@yahoo.co.nz>.
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 <ok...@gmail.com>
To: "users@isis.apache.org" <us...@isis.apache.org>
Cc: "users@isis.apache.org" <us...@isis.apache.org>
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 <da...@yahoo.co.nz> 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
>
Re: Transaction Handling
Posted by Okwui <ok...@gmail.com>.
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 <da...@yahoo.co.nz> 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
>
Re: Transaction Handling
Posted by David Tildesley <da...@yahoo.co.nz>.
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
Re: Transaction Handling
Posted by Okwui <ok...@gmail.com>.
Essentially therefore there is no way.
Sent from my iPad
On Jul 20, 2013, at 9:04 AM, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Isis automatically wraps each action (or interaction) in a transaction; so
> all changes made will be done atomically.
>
> That's either a good thing or a bad thing.
>
> It's a good thing in that it "just works".
>
> It's a bad thing in that, if you wanted to divide your action into separate
> transactions, well, you can't. The only control we give you is to "flush"
> any pending changes, using DomainObjectContainer.flush(). That said, we do
> this automatically in any repository queries, so even then you can probably
> ignore it.
>
> I can think of ways of getting more control than that (eg publishing an
> event and using the scheduler service to consume it asynchronously), but
> would probably qualify as over- engineering.
>
> HTH
> Dan
>
>
>
> On 20 July 2013 02:14, Okwui <ok...@gmail.com> wrote:
>
>> I am trying to implement a business system. I want to be able to make a
>> set of changes to different entities which will either succeed or fail
>> together. Is there a way to manage transactions?
Re: Transaction Handling
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Isis automatically wraps each action (or interaction) in a transaction; so
all changes made will be done atomically.
That's either a good thing or a bad thing.
It's a good thing in that it "just works".
It's a bad thing in that, if you wanted to divide your action into separate
transactions, well, you can't. The only control we give you is to "flush"
any pending changes, using DomainObjectContainer.flush(). That said, we do
this automatically in any repository queries, so even then you can probably
ignore it.
I can think of ways of getting more control than that (eg publishing an
event and using the scheduler service to consume it asynchronously), but
would probably qualify as over- engineering.
HTH
Dan
On 20 July 2013 02:14, Okwui <ok...@gmail.com> wrote:
> I am trying to implement a business system. I want to be able to make a
> set of changes to different entities which will either succeed or fail
> together. Is there a way to manage transactions?