Forums

by JADE Kid - Ray Hidayat >> Wed, 12 Jul 2000 2:43:51 GMT

When you update a non-shared transient, I realise that you don't need an instruction to tell JADE when you are starting your transaction, and when you are ending it.

So when you update a transient, isn't this an "Instantaneous Transaction" (see post titled "Instantaneous Transactions")?
Is there a way to do this with persistent objects and shared transients? Does the transient ever get locked during the process?

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

by Craig Shearer >> Wed, 12 Jul 2000 3:13:05 GMT

As far as I know, the beginTransientTransaction and commitTransientTransaction are simply locking instructions to prevent undesirable simultaneous access to a shared transient object. They simply prevent another process from accessing the object until you've finished updating it.

Craig.

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.

by JADE Kid - Ray Hidayat >> Thu, 13 Jul 2000 6:27:18 GMT

Yes I am completely aware about these 'Transactions', which fail or succeed as a whole. When I learnt this, I tried to put all my code into logical blocks or transactions.

But I'm sure that these instantaneous and non-undoable transactions could be added into JADE couldn't they?
Or maybe some solution to loading large files...
You never know, could be useful.

Is the JADE Transaction Cache stored on the Hard Drive or in the Memory (Assuming that there is so much memory, there is need for virtual memory)?

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

by Craig Shearer >> Thu, 13 Jul 2000 21:11:40 GMT

<snip>

But I'm sure that these instantaneous and non-undoable transactions could be added into JADE couldn't they?
Or maybe some solution to loading large files...
You never know, could be useful.

No!!! Sounds like a recipe for major database corruption to me!!!

Craig.

by Dean Cooper >> Thu, 13 Jul 2000 21:43:23 GMT

But I'm sure that these instantaneous and non-undoable transactions could be added into JADE couldn't they?

The question isn't whether or not they can be added, it's do we need them? I think not.

As already mentioned, the problem you had loading the file was to do with cache and the fact that you were concatenating every chunk into a string property on an object, thus creating a huge object. Cache must be at least as large as the single largest object you want to access. You would have run into the same problem using non-shared transients, when transactions aren't even involved!

I presume what you mean by an "instantaneous transaction" is the ability for any update to a persistent object to be reflected immediately in the database without needing to code beginTransaction and commitTransaction? Can you give us an example of when you'd need this?

If you consider the following code:
begin
Transaction;
obj.string1 := "hello";
obj.string2 := "to the";
obj.string3 := "world";
commitTransaction;

How is your "instantaneous" transaction different from rewriting the above code as:
begin
Transaction;
obj.string1 := "hello";
commitTransaction;begin
Transaction;
obj.string2 := "to the";
commitTransaction;begin
Transaction;
obj.string3 := "world";
commitTransaction;

except for the fact that you don't have to code begin/commitTransaction? Why would you want to do this? Committing the update in a single transaction is far more efficient, and sensible.

Dean.

by JADE Kid - Ray Hidayat >> Fri, 14 Jul 2000 7:08:26 GMT

Okay everyone! I understand. I have used a binary array. So my problem is solved! Thanks to everyone who replied to this thread!

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com