Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread Locking and Concurency question
Fri, Mar 15 2013 6:19 AMPermanent Link

Beni

Hello,

I have an application using ElevateDB database. At this moment I'm using the pessimistic row locking protocol. To test it I started 2 different instances of the same application, loaded a list of records using a query. I did manage to handle the situation when both applications are trying to edit the same record. How can I handle the situation when one of the applications is done with the editing and the other application still has the old properties for the record? Is there any way to find out if the record is out of date? The documentation does mention something about the EDB_ERROR_ROWMODIFIED but this happens only when the locking is optimistic.

Thanks,
Beni.
Fri, Mar 15 2013 11:07 AMPermanent Link

Fernando Dias

Team Elevate Team Elevate

Beni,

Having a sensitive result set is the first step.
If you want to be sure that you are looking at 'live' data you must ensure that your queries are Sensitive. If you are using TEDBTable then it's 'live' data for sure, if it's TEDBQuery, then you have to set TEDBQuery.RequestSensitive to TRUE and follow the set of rules that allow your queries to return a sensitive result set (there's information about what rules in the manual, or if you like we can guide you).
After that, both TEDBQuery and TEDBTable have a Refresh method that as you can guess Smileyrefreshes the data you are seeing.

--
Fernando Dias
[Team Elevate]
Fri, Mar 15 2013 11:43 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Beni


I'm not sure what it is you want to achieve here. With pessimistic row locking ElevateDB handles the situation quite well by itself.

Try running two instances of EDBManager, run the same query in each making sure to ask for a sensitive result set. Start editing in one, switch to the other and it tells you that you're not allowed to edit that row

---------------------------
ElevateDB Manager
---------------------------
ElevateDB Error #1005 Cannot lock the row in the table Test.
---------------------------
OK  
---------------------------

Once the original edit is posted trying to enter data into that column for that row results in the data being refreshed.

If what you want is for the second instance to show the new data as soon as the first has posted it then you'll have to implement some sort of custom messaging to let all instances know that the data is changed and, as Fernando suggests call Refresh.

If its not possible / convenient to implement some form of messaging then all you can do is have a timer and refresh the tables / queries at intervals.

Roy Lambert [Team Elevate]
Fri, Mar 15 2013 2:45 PMPermanent Link

Beni

Thanks for your answers!

I just notice something I didn’t see until now! Yes, I’m using sensitive queries and I handled the situation when 2 applications were trying to edit the same record (#1005 error code). My problem was related to a record changed in one application and already loaded in another application. I just notice that when you go into edit mode the record (in the second application) is updated (refreshed) silently which is interesting … but is this the right solution? I will have to explain to my users that what they see may change when they are trying to change it. Wouldn’t be a better solution to raise an error when the user tries to change an out of date record – when the locking is attempted?

I made something similar “manually” (with another database management system): kept a table with last change date for the records (record primary key, record type and datetime when the last time the record was saved) and every time when the user was trying to edit a record the last change date for that record in the local session was compared with the last change date from the database. For sure such a mechanism can be more efficient when it is implemented in the database engine.
... just a suggestion/idea

... and again,
thanks for your answers,
Beni.
Fri, Mar 15 2013 3:30 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Beni,

<< I just notice something I didn’t see until now! Yes, I’m using sensitive
queries and I handled the situation when 2 applications were trying to edit
the same record (#1005 error code). My problem was related to a record
changed in one application and already loaded in another application. I just
notice that when you go into edit mode the record (in the second
application) is updated (refreshed) silently which is interesting … but is
this the right solution? I will have to explain to my users that what they
see may change when they are trying to change it. Wouldn’t be a better
solution to raise an error when the user tries to change an out of date
record – when the locking is attempted? >>

This is the property that you want (TEDBSession):

http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=delphi&version=7&comp=TEDBSession&prop=RecordChangeDetection

If you set it to True (default is False), then an Edit will raise a "Row
modified" exception that you can trap in an OnEditError event handler and
use to notify the user.  You can then just retry the operation and it will
continue on as normal.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com
Fri, Mar 15 2013 3:37 PMPermanent Link

Beni

"Tim Young [Elevate Software]" wrote:

Beni,

<< I just notice something I didn’t see until now! Yes, I’m using sensitive
queries and I handled the situation when 2 applications were trying to edit
the same record (#1005 error code). My problem was related to a record
changed in one application and already loaded in another application. I just
notice that when you go into edit mode the record (in the second
application) is updated (refreshed) silently which is interesting … but is
this the right solution? I will have to explain to my users that what they
see may change when they are trying to change it. Wouldn’t be a better
solution to raise an error when the user tries to change an out of date
record – when the locking is attempted? >>

This is the property that you want (TEDBSession):

http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=delphi&version=7&comp=TEDBSession&prop=RecordChangeDetection

If you set it to True (default is False), then an Edit will raise a "Row
modified" exception that you can trap in an OnEditError event handler and
use to notify the user.  You can then just retry the operation and it will
continue on as normal.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

GREAT!!!!

Thanks a lot!!!!
Image