(*

Make the transaction context system more usable.

Have BeginUpdate/EndUpdate methods for a row so that the entire record can be 
updated a column at a time and only need to announce once that it's values were updated.

--------------------------
Pessimistic record locking
--------------------------

NOTE: THIS HAS BEEN PARTIALLY IMPLEMENTED!

There are two cases that need to be allowed. 

CASE 1)	If the dataset's transaction is lock-nowait then a much simpler method can be taken.
	< This has now been implemented in the IB_Cursor component. >

Prior to going into update mode simply produce a bogus update statement that will not actually
make any changes to the data. If it is successful then the lock is in place automatically due
to InterBase's versioning engine. If it fails then someone else has already updated or deleted
that record. Now, even though there has been a bogus update made, because we are still in the same
transaction and cursor context the true updates can be processed right over the top of the bogus one.

CASE 2)	If the dataset's transaction is lock-wait then the lengthy approach proposed below is needed. 
	< Not implemented yet because I don't think this combination is likely to be used. >

Make an internal sub-transaction that implements a pessimistic record locking mechanism.
When a record is put in update mode issue a bogus update statement
against the row through the sub-transaction. This will lock it. Only allow the
dataset to go into update mode if this lock is obtained. This effectively
keeps out changes from other sources if they too follow this convention. Plus, they 
will only see the contention if they actually attempt to touch the record. Otherwise,
they will simply be able to see the latest committed record at all times without any
read contention at all. Then, in another subtransaction, or the same if lock-wait is used,
probably preferable in order to not have too many transactions being generated. Apply the
actual updates against the server and roll-back the transaction with the bogus updates.
This then allows the new and waiting updates to be applied free of contention.

A ha! Make each update have it's own bogus transaction and so it is released
upon the post. Because then the post is still a part of it's own transaction and can be
rolled back or committed. It also takes the place of the former bogus update/delete in keeping
the record locked until the transaction is completed. Therefore, I need not cache the updates!

It will be necessary to use multiple threads to make this work. 
The bogus transaction will need to be processed by a sub-thread. 
While the true updates are applied in a WAIT manner against the bogus updates in limbo
there is a trap. The thread is stuck and then cannot do a rollback in order to make it all work.
It is also not desirable to do a rollback before actually applying the true updates. This gives a
very brief window of opportunity for another process to block the true update.

Pessimistic locking should not be the default behavior.
It will be transaction intensive to the server since each single update will use a
single transaction to provide the locking mechanics.

--------------------------

*)