| Subject | Re: [IBO] Either Grid shows old value & allows post of new with no warning (tiCommit) or cannot see new value (tiConcurrency) |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-08-01T00:37:28Z |
At 05:10 AM 1/08/2003 +0930, you wrote:
conditions, where you would instantiate a Session + Connection +
Transactions + Queries bundle for each instance of a thread and destroy it
when the thread finished.
tiConcurrency with CommitRetaining causes the original transaction context
to be preserved. The user (or transaction) who does the changes can see
his own changes but not those done by others. The only way for a
tiConcurrency transaction to get a fresh view of database state is to do a
hard commit and requery.
In the case of tiCommitted with CommitRetaining, the original transaction
context is still preserved, but the difference is that the transaction gets
a constantly updated view of the records that are updated. However, you
won't see those updated records in your *grid* unless you deliberately
cause them to be fetched from the server. As you are no doubt aware, IBO
has a number of ways to synch the buffers with the database in these
conditions, without *necessarily* performing a full requery.
from, or arrive to. There is no way that the server can detect that a user
is editing a value in a field. When your user is doing stuff in an "edit
mode" (I/U/D), it is all happening in the application. Post is the first
client-side action that the server responds to. That's the first point at
which the server can deal with a lock conflict. How it responds to a lock
conflict depends on the attributes of the transaction.
The situation with an optimistic locking system is that readers can see a
version of every record that is in the scope of their SELECT
specification. The version they see is the most-recently committed
version, in the context of their transaction.
-- With tiConcurrency + CommitRetaining, the transaction continues to see
the recversions it saw 'way back when StartTransaction was first called,
plus the updated view of any records that this transaction has changed.
-- With tiCommitted, the transaction's view (what the server will allow it
to see) gets updated each time another transaction commits a change to a
record that this transaction can see -- even with
CommitRetaining. However, the client buffers won't get updated unless you
deliberately update them - so, when you're thinking about "what's in the
grid", you're not thinking about "what's happened on the server" unless you
deliberately synchronise the dataset's buffer with the Read Committed
transaction's latest view.
Helen
>With tiCommitted the GridNot only unnecessary, but undesirable - except under multi-threading
> shows and old value that has been changed and committed by another
> allows post of new with no warning
>
>With tiConcurrency the Grid
> does not allow refresh of new values provided by another
> cannot update
>
>What do I have to do to have:
> Edit a changed field causes a PreviousValueChanged message
>and
> Allows refreshing of the row?
>
>I have separate transactions for each query.
>
>With a single user and one application, is it necessary to also have separate
>connection components on the form for each query?
conditions, where you would instantiate a Session + Connection +
Transactions + Queries bundle for each instance of a thread and destroy it
when the thread finished.
>Does using CommitRetaining cause the inability of tiConcurrency edits to notUmmm (trying to process those double negatives...)
>be visible to another user?
tiConcurrency with CommitRetaining causes the original transaction context
to be preserved. The user (or transaction) who does the changes can see
his own changes but not those done by others. The only way for a
tiConcurrency transaction to get a fresh view of database state is to do a
hard commit and requery.
In the case of tiCommitted with CommitRetaining, the original transaction
context is still preserved, but the difference is that the transaction gets
a constantly updated view of the records that are updated. However, you
won't see those updated records in your *grid* unless you deliberately
cause them to be fetched from the server. As you are no doubt aware, IBO
has a number of ways to synch the buffers with the database in these
conditions, without *necessarily* performing a full requery.
>Why doesn't a tiCommitted change using CommitRetaining by one user notIt's not clear where you think a "RecordVersionChanged message" would come
>cause a RecordVersionChanged message by a 2nd user when changing the value
>in the field?
from, or arrive to. There is no way that the server can detect that a user
is editing a value in a field. When your user is doing stuff in an "edit
mode" (I/U/D), it is all happening in the application. Post is the first
client-side action that the server responds to. That's the first point at
which the server can deal with a lock conflict. How it responds to a lock
conflict depends on the attributes of the transaction.
The situation with an optimistic locking system is that readers can see a
version of every record that is in the scope of their SELECT
specification. The version they see is the most-recently committed
version, in the context of their transaction.
-- With tiConcurrency + CommitRetaining, the transaction continues to see
the recversions it saw 'way back when StartTransaction was first called,
plus the updated view of any records that this transaction has changed.
-- With tiCommitted, the transaction's view (what the server will allow it
to see) gets updated each time another transaction commits a change to a
record that this transaction can see -- even with
CommitRetaining. However, the client buffers won't get updated unless you
deliberately update them - so, when you're thinking about "what's in the
grid", you're not thinking about "what's happened on the server" unless you
deliberately synchronise the dataset's buffer with the Read Committed
transaction's latest view.
Helen