>>>>Programming is all about trade offs. Following patterns blindly
is
>never
>>>>a good idea.
>>>I agree. What was the part where I was following patterns blindly?
>>By assuming that a session facade with one overall transaction was
>the only useful pattern.
>Oh come on. How is the example I mentioned not suitable for
session
>facade pattern? If that is not, then what is? Have you
suggested a
>better alternative? Or do you just like preaching?
>I have already explained that it's one large transaction over many
domain objects. What you haven't done is explain why one transaction
is required by your use case, >with the exception of some hand waying
argument about ACID.
I am getting a bit tired of this since you seem to have decided to
refuse to understand my point. If you seriously think that for the
example which I have repeatedly talked about in the previous messages
(displaying a. on one case a cd and it's corresponding artist and b.
on the other one artist and corresponding cds) the best approach
would be to handle transactions manually with JTA, having separate
transaction for fetching data for artist and for fetching data for
records (or a separate transaction for each record?), then fine.
That's you suggestion, it does not sound good to me, but then what
the hell do I know?
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
