Re: [CFCDEV] Re: where to put transactions?
Tom Chiverton
> +1 for Service layer as the place to manage transactions that span multiple
> domain objects, or multiple kinds of domain objects.
What if you are using (ColdSpring) AOP to write the service layer for you ?
Then you're stuck with putting the transaction in each Manager's method, and
wrapping calls to all the other Managers that make up that method too.
Which seems like massive overkill, and certainly not elegant, and I'm not sure
CF8 finial supports nested transactions...
--
Tom Chiverton
Helping to greatly build sticky m-commerce
on: http://thefalken.livejournal.com
****************************************************
This email is sent for and on behalf of Halliwells LLP.
Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority.
CONFIDENTIALITY
This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008.
For more information about Halliwells LLP visit www.halliwells.com.
Brian Kotek
Tom Chiverton
> I'm not sure what you mean by having ColdSpring "write the service layer
> for you", since usually you already have service layer objects and AOP just
> wraps them to add some extra functionality (is this what you mean?).
Fairly much.
So far though our Managers look like nothing much more than a Facade to
Reactor (because we're just doing CRUD and a bit of search, maybe), AOP then
sits atop that to provide security (through session tokens which it decodes
to usernames).
We've not had to cross this transactions bridge yet, but we will have to once
some of the bigger projects we have backed up come up again.
> You're right though, nested transactions didn't
> make it into CF8 (which sucks since I saw it demoed during the beta tour).
Bah. That would simplify this whole argument :-)
--
Tom Chiverton
Helping to widespreadedly harness back-end relationships
Barry Beattie
> > make it into CF8 (which sucks since I saw it demoed during the beta tour).
>
> Bah. That would simplify this whole argument :-)
I wonder why they dropped them for the final release? I too was under
the impression that nested transactions made it to the final release,
and then was bitten quite badly when I tried to use it.
moving transactions further and further up the service layer is all
very well but it's the different places where you want transactions
run that's giving me grief.
(since I started this thread) I can bypass part of the issue by
changing databases and turning my inserts into Sproc's but IMHO it's
still a pain. I'll certainly be having a few words with Ben Forta when
he's on tour here in a couple of weeks...
Tom Chiverton
> moving transactions further and further up the service layer is all
> very well but it's the different places where you want transactions
> run that's giving me grief.
Well that's the thing, isn't it :-)
Without nested transactions, you have to put them at the top level, which
means every service method (unless you use AOP) has to care. That may or may
not be a good thing, but programmers forget things.
Conceptually I'd like my manager1.get() to be one transaction,
manager2.update() another, fileLogger.write() a third, with one 'update
record' transaction around the lot - belt and braces defensive programming.
> still a pain. I'll certainly be having a few words with Ben Forta when
> he's on tour here in a couple of weeks...
It'd be interesting to see why it's not there in final, and if it's planed to
go into a point update / patch roll up / updater.
--
Tom Chiverton
Helping to continuously expedite corporate ROI
Barry Beattie
> manager2.update() another, fileLogger.write() a third, with one 'update
> record' transaction around the lot - belt and braces defensive programming.
yep, that's the beast.
and the replacement to that (to me - correct me if I'm wrong) is to
start moving a lot of that logic directly into the database which
flattens the app, cuts down code reuse and makes maintainance and
enhancements like walking on eggshells.
Tom Chiverton
> and the replacement to that (to me - correct me if I'm wrong) is to
> start moving a lot of that logic directly into the database
And have a single 'doFoo' stored proc that updates/creates all the various
tables ?
Yeah, been there, made scrambled eggs ;-)
--
Tom Chiverton
Helping to continually customize professional deliverables
on: http://thefalken.livejournal.com
****************************************************
This email is sent for and on behalf of Halliwells LLP.
Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority.
CONFIDENTIALITY
This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500.