by
Dean Cooper >> Wed, 12 Jul 2000 3:32:34 GMT
The concept of a transaction is much more than merely something you have to do in order to update a persistent or shared transient object. The purpose of a transaction is to bracket a sequence of actions into one logical operation that is either committed or aborted in its entirety. This affects locking and concurrency, and preserves database integrity by making sure that incomplete operations aren't reflected in the database, and that other processes can't see the results of an update that hasn't yet completed (dirty reads).
For the process that is actually performing the transaction, updates are reflected "instantaneously", as you put it. For example, consider the following code:
begin
Transaction;
aCustomer.name := "New Name";
write aCustomer.name;
..... the rest of the code ...
commitTransaction;
For the process that's executing this code, the name of the customer object is changed (in cache) immediately. But any other processes in the system won't see the changed name until the transaction has committed, which is what you want (because you, or JADE, may decide to abort it).
The problem you describe in your "Instantaneous Transaction" post isn't transactions at all (instantaneous or otherwise). The problem is cache size, and I see that Craig has already pointed this out.
Right now, the transient transaction mechanism is a means of concurrency control (ie: to prevent multiple processes updating the same object at the same time), because a process performing a transient transaction will exclusively lock those shared transients it updates. Updates to shared transients are reflected immediately (obviously) and there is (currently) no rollback of transient transactions. If you want to read more about shared transients, have a look at the Shared Transients technical paper written by Roger Jarquin (
http://news.jadeworld.com/developers/tpapers.htm).
Dean.