That is one reason, but it's not clear that is the original reason, or are
you the original poster? The original poster indicated the restriction was
an arbitrary one put on by management, not one imposed by a system which
can't serve as an XA resource. Maybe I read too much into it.
Sorry if I came across saying you can't do it, more my point was if it's an
arbitrary restriction push back. Clearly you can use compensating
transactions to handle this case, but they will introduce whole new points
of failure to your program and why would you voluntarily use autocommit and
compensating transactions when you could have something like container
managed transactions?
Cheers
Jay
-----Original Message-----
From: Fei Li [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 02, 2001 2:07 PM
To: [EMAIL PROTECTED]
Subject: Re: Designing Application w/o Commitment Control
Jay:
Somebody work on legacy system. That's why.
-----Original Message-----
From: Jay Walters [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 02, 2001 4:15 AM
To: [EMAIL PROTECTED]
Subject: Re: Designing Application w/o Commitment Control
Interesting question, but exactly what do you mean? That you must use
autocommit instead of explicit control? and why have they put this
restriction on you? Is this same restriction true of other systems that
your company has built or is using? I doubt it, seeing the company is in
the Financial Services market.
If you are using any of the major database products, if you don't commit
using either explicit commit or autocommit your changes will never be saved.
So they'll let somebody control commit, perhaps just the database.
If in fact they are restricting you to autocommit, then I would take the
approach to demonstrate that recovery of failed business transactions will
be non-trivial and potentially error prone. This is almost an ethical
question in my mind, who cares about J2EE vs MS, who are these people and
what are they thinking?
A potentially relevant example would be, I received a mortgage payment from
a customer and credited the money to their account (AUTOCOMMIT happens) then
something goes wrong before the transaction finishes. Hope I remember to
debit their account before I try again. I would work at the logical level
and show how this restriction will impose the same condition on any
platform. This is a simple issue of showing the SQL steps required for some
non-trivial transaction and how it will break down if you must use
autocommit. I would suggest management discuss this impressive new idea
with your customers as well. No sense building the code if it will never
really work right, and that nobody would want to buy.
There is clearly something odd going on, and I'd work to spend some time
upfront killing any MS solution along with yours because if they're under
the same restriction, even if they're happier their solution won't work very
well either. Is this your first effort using J2EE?
If the issue is that you cannot in your application code use
commit/rollback, then an EJB container is a perfect fit as you can use
container managed transactions and everything will be right in the world.
This would correspond to using MTS in the MS world. I sense this is not the
issue though from your request for help.
Cheers
Jay
===========================================================================
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".
===========================================================================
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".
===========================================================================
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".
