Re: Service Object events and LockMgr

Question

On the option that you have considered, I have implemented the same model
in my previous project (using Java/RMI), but I felt that it is more than
what is normally needed for concurrency protection.
I can suggest another option that is worth considering which is in place in
our app for concurrency.
Almost every table in our db has created By, created On, modifed By,
modified On columns. The parent class of all business objects has
attributes that correspond to these four columns. In addition to these
four, there is a fifth attribute (introduced when concurrency was built)
called originalModifiedOn. Upon retrieval from the db, it is set to
modifiedOn value (from the db), during UPDATE, the value in this column is
added part of the WHERE clause. So when the second user tried to do save
the same object, the underlying db update will get a 'zero rows updated'
which is translated into an application error 'possible concurrency
error'. The user re-retreives the now 'stale' object before applying their
edits.
A lot of these things are and can be built into the framework imposing very
little work that each Object needs to do to have concurrency protection.
I am not sure if there is a mention in the Patterns paper of this model,
but it is very easy to implement and supports what is needed.
Kishore Puvvada's Mail
[email protected] on 07/28/99 01:47:00 AM
To: [email protected]@INTERNET
cc: (bcc: Kishore Puvvada/HQ-IS/TAL)
Subject: Service Object events and LockMgr
Hi folks,
We're currently looking at strategies for dealing with the simultaneous
updates to the database from multiple clients (concurrency
management). That is when two (or more) clients load the same object to
edit it, then make different changes and save them to the database.
We have a copy of a Forté document (from the "Patterns" course, I
think) which describes three methods of dealing with this:
1) Lock the database table row as soon as a client select it for editing
and hold the lock until it is saved.
2) Immediately before 'saving' check that the database hasn't changed
(either by reading what's there before updating, or by using a huge
'where' clause that contains all unchanged fields)
3) The Forté "LockMgr" pattern, which uses a service object with notifier
proxies to allow locking and updating notification between the clients.
Option 3 is obviously the most robust method, but it requires a fair
amount of coding and could also be a bottleneck for database reads and
writes.
But I have another option for which I was looking for opinions. What if
we had a "Change Event manager" which broadcast an event every time
a change is made to the database. Each business class would have its
own event. If the event had the object's primary key as a parameter, then
clients editing that particular object type could check to see if the object
currently on screen is the one that changed. That way you could disable
the 'save' until they had refreshed their on-screen data.
It's not particularily elegant, but it's reasonably simple to implement. It
also deals with changes sent across our WAN from other database
servers.
But this option is only worthwhile if you can replicate the "Change Event
manager" SO and still register for an event on the client. Can clients
register for SO events and receive an event generated by any of the SO's
replicates? Or when you register for an SO's event do you register for
only one instance of the SO?
Thanks in advance for any answers.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: [phone]
Shakespeare Road, Napier, New Zealand. Fax: [phone]
Providing Integrated Software to the Meat Processing Industry for over 10
years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:
http://pinehurst.sageit.com/listarchive/forte>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>

Answer 1

On the option that you have considered, I have implemented the same model
in my previous project (using Java/RMI), but I felt that it is more than
what is normally needed for concurrency protection.
I can suggest another option that is worth considering which is in place in
our app for concurrency.
Almost every table in our db has created By, created On, modifed By,
modified On columns. The parent class of all business objects has
attributes that correspond to these four columns. In addition to these
four, there is a fifth attribute (introduced when concurrency was built)
called originalModifiedOn. Upon retrieval from the db, it is set to
modifiedOn value (from the db), during UPDATE, the value in this column is
added part of the WHERE clause. So when the second user tried to do save
the same object, the underlying db update will get a 'zero rows updated'
which is translated into an application error 'possible concurrency
error'. The user re-retreives the now 'stale' object before applying their
edits.
A lot of these things are and can be built into the framework imposing very
little work that each Object needs to do to have concurrency protection.
I am not sure if there is a mention in the Patterns paper of this model,
but it is very easy to implement and supports what is needed.
Kishore Puvvada's Mail
[email protected] on 07/28/99 01:47:00 AM
To: [email protected]@INTERNET
cc: (bcc: Kishore Puvvada/HQ-IS/TAL)
Subject: Service Object events and LockMgr
Hi folks,
We're currently looking at strategies for dealing with the simultaneous
updates to the database from multiple clients (concurrency
management). That is when two (or more) clients load the same object to
edit it, then make different changes and save them to the database.
We have a copy of a Fort&eacute; document (from the "Patterns" course, I
think) which describes three methods of dealing with this:
1) Lock the database table row as soon as a client select it for editing
and hold the lock until it is saved.
2) Immediately before 'saving' check that the database hasn't changed
(either by reading what's there before updating, or by using a huge
'where' clause that contains all unchanged fields)
3) The Fort&eacute; "LockMgr" pattern, which uses a service object with notifier
proxies to allow locking and updating notification between the clients.
Option 3 is obviously the most robust method, but it requires a fair
amount of coding and could also be a bottleneck for database reads and
writes.
But I have another option for which I was looking for opinions. What if
we had a "Change Event manager" which broadcast an event every time
a change is made to the database. Each business class would have its
own event. If the event had the object's primary key as a parameter, then
clients editing that particular object type could check to see if the object
currently on screen is the one that changed. That way you could disable
the 'save' until they had refreshed their on-screen data.
It's not particularily elegant, but it's reasonably simple to implement. It
also deals with changes sent across our WAN from other database
servers.
But this option is only worthwhile if you can replicate the "Change Event
manager" SO and still register for an event on the client. Can clients
register for SO events and receive an event generated by any of the SO's
replicates? Or when you register for an SO's event do you register for
only one instance of the SO?
Thanks in advance for any answers.
Cheers,
Duncan Kinnear,
McCarthy and Associates, Email:
[email protected]
PO Box 764, McLean Towers, Phone: [phone]
Shakespeare Road, Napier, New Zealand. Fax: [phone]
Providing Integrated Software to the Meat Processing Industry for over 10
years
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:
http://pinehurst.sageit.com/listarchive/forte>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/forte>