Transactions & Mapping Methods

[ConvertFromOldNGs]

by Wilfred Verkley >> Sun, 24 Jun 2001 21:18:11 GMT

If have a single reference an persistent object (a custom "session" object) thats being read from many places. This object is very often just null (because its not needed or invalid), but when its being read, i want it to automatically initialized.

A tidy way i normally do it with transient objects is to put this initialization code in a "mapping" method. If I do this with persistent objects, where do i put the begin&commitTransaction calls?

I know the normal rule in most Jade applicatiZons ive seen is to put them at the outermost level (normally in the UI layer), but it seems tedious and ineffecient to surround all references to it with a transaction when 99.9% of the time its only being read.

My current inclination is to put the transaction calls in the mapping method itself, with a "process.isInTransactionState" call to check whether we are already in a transaction or not. Is this good practice ?


mySession(set: Boolean; _value: CustomerSession io) mapping, updating;begin

if not set then
if mySession= null then
if not process.isInTransactionState then
beginTransaction;
create mySession;
commitTransaction;
else
create mySession;
endif;
endif;
_value := mySession;
endif;
end;


Cheers,

Wilfred.

[ConvertFromOldNGs]

by Carl Ranson >> Mon, 25 Jun 2001 0:36:44 GMT

It might just be my opinion, but I don't like this idea for the following reasons:

1.It makes it really easy to loose track of where the transactions occur in your system.
2.It can (although admittedly not very often) introduce locking issues.

Consider if you did a transaction duration lock on something before a transaction (to ensure you had the latest version, prevent updates to it etc), then did a transaction

sharedLock(foo); // no one can update foo 'til after my transaction...begin Transaction
......whatever in here.
commitTransaction

now, if someone puts any code between the sharedLock and thebegin Transaction that sets your reference, it will create a window where foo could be updated by another process. This happens because the commitTransaction in your mapping method releases all transaction duration locks.

This sort of bug is a nightmare to track down in a production system, which is reason enough to avoid it in my opinion. Your better to have the transaction points as obvious as possible.

Regards,
CR

[ConvertFromOldNGs]

by Wilfred Verkley >> Mon, 25 Jun 2001 4:55:26 GMT

It might just be my opinion, but I don't like this idea for the following reasons:

1.It makes it really easy to loose track of where the transactions occur in your system.
2.It can (although admittedly not very often) introduce locking issues.

Good arguments. Im not sure if i agree in this specific case, but ill investigate if i can move the code in an easy way to a higher level.


Cheers,

Wilfred.

[ConvertFromOldNGs]

by Torrie Moore >> Tue, 26 Jun 2001 6:24:56 GMT

Wilfred

Perhaps the references should be automatically set up when you create the object. That way the references are always valid and the need for transactions in the mapping methods is removed.

Torrie Moore