[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 238
  • Last Modified:

Transactions and CORBA

I have corba server which is connected to a database and
I use that database trough the client program.
I can make queries, updates etc. but now I have the
classic update problem.

A gets record:
'SELECT FIRSTNAME FROM TABLE WHERE ID = 1000'

B gets same record:
'SELECT FIRSTNAME FROM TABLE WHERE ID = 1000'

After this B updates and the A updates.
B's update is lost. Of course B shouldn't
be able to update, because A got the
record first.

How do I solve this problems in Delphi?
I didn't get any errors when made the
SQL query with A and then update with B

I'm using following strategy:

E.g. Get list of users
1. Call method GetUsers(userlist: TList), which is method of my DBHandler
class.
2. Create SQL query and execute it.
3. Loop trough resul, create TUser objecst
and add them to the userlist.
4. Show the users in some component e.g.
in TListview component.

I tried to use TDataClientSet.ApplyUpdates(0);
and CancelUpdates, but I only get "Unexpeceted
Error" with following code:

name := 'foo';
CorbaConnection1.Connected := True;
ClientDataSet1.Close;
sql := 'UPDATE TABLE SET FIRSTNAME = ' + '''' +
nimi + '''' + ' WHERE ID = 1000';
ClientDataSet1.CommandText := sql;
ClientDataSet1.Execute;
ClientDataSet1.CancelUpdates //unexcepted error here

Execute goes ok, so there is nothing wrong in the SQL.

It seems that I can use CancelUpdates/ApplyUpdates
only if I'm using some database with DBGrid.
Now the Execute command makes all the changes
in the database right away.

I'm using Solid Server as a database server.
0
tonitop
Asked:
tonitop
1 Solution
 
ITugayCommented:
hi tonitop,

Yes it's classical update problem. You need to prevent another users to get record for editing if one of them already get it. You need to have additional field to keep information about locks. It may be integer field, let its name be IDL. Normally it contain "0".

1. try mark record as locked
"update thetable set IDL=:id_user where ID=1000 and IDL=0"
nothing happen if another user "lock" it because of IDL<>0 in this case

2. get for editing
"select * from thetable where IDL=:id_user and ID=1000"
if query returns empty result then another user get record for editing

3. if previous action is success then make your changes and "unlock" record
"update thetable set IDL=0 where ID=1000"


It's usual way to mark record as locked in not locks supprted database.

----
Igor.
0
 
lorenkCommented:
ToniTop,
The answer is a little more complex than what you might think.  First off, I would suggest NOT using the ClientDataSet objects.  These ar ejust not meant for these types of transactions.  I have created many 3-tier apps and never used them.  The appropriate way to do this is to keep the locking within the CORBA object itself.  This of course means that ALL apps that touch the database NEED to go through the CORBA object.  This makes sense though.  So, you keep a log of what apps have which records open and make sure that only the one with the "lock" makes the change stick.   This way, you can also update all clients IMMEDIATELY when the "locked" client makes a change.  And then a different client can get the "lock."

The log I am referring to in my apps is usually a TLIST of objects which contain the ID of the client and the ID of the record they are accessing.

This is the best way to do locking IMHO.  I never like to rely on the DB to do it.

Loren
0
 
tonitopAuthor Commented:
Answer accepted
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now