[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: transaction scoping
On Wed, 06 Dec 2000, Rob van Oostrum wrote:
> sorry about that 'quick & dirty' posting of mine =)
>
> > -----Original Message-----
> > From: Falko Braeutigam [mailto:falko@smb-tec.com]
> >
> > In ozone a state of an object can only be changed by a method
> > of the class. [...]
>
> Yes, I didn't question that for a second. Perish the thought ... ;)
>
> > > If one of these calls fails, I want to roll
> > > the whole thing back. From what I gather from the
> > documentation, this isn't
> > > covered by the current stuff. Has anyone given any thought
> > about how to
> > > solve this?
> >
> > No a lost you, I guess. Can you explain more?
>
> Let me draw a little expample. Not an elegant design, but I hope it
> clarifies the point I'm trying to make. Say I have a class Rob and a class
> Car. Let's say my instance of Car breaks down, and this fact pisses me off.
> I might want to call myCar.setBrokenIndicator( true ) and myRob.setMood(
> Constants.PISSEDOFF ). Both these methods have been defined as operations
> that alter the state of their respective objects. By my understanding, ozone
> would start and commit separate transactions for both these methods.
No. It just starts a new transaction for each method if the methods are called
from the client (and there are no transaction boundaries explicitely defined).
If both methods are logically part of one transaction and you are calling them
subsequently from the client then you are producing wrong code that not
reflects your intention. This fact is very important for ozone application
design because susequently calling the methods from the client is terrible slow
compared to in-server calls. This is the reason why you should not use
explicite transaction demarcation _and_ try to be transactional correct (see
your example). If both conditions are met then you have a (transactional)
correct _and_ fast ozone application design.
In other words: if both methods are part of a (business) transaction, then you
should write a (database) method which calls the methods (from inside the
server). This method represents the business transaction.
Falko
>
> What I would like to be able to do is start a transaction for the method
> that calls both these methods, and have myCar.setBrokenIndicator() and
> myRob.addMindset() join this transaction (or better yet, have each of them
> start a nested transaction). After both calls, the transaction would be
> committed, assuring that both calls are rolled back if any part of the
> commit (or any of the nested commits) fails.
>
>
> hope this explains things better.
> Rob
--
______________________________________________________________________
Falko Braeutigam mailto:falko@smb-tec.com
SMB GmbH http://www.smb-tec.com