advcomputer
Posts: 68
|
| Posted: 03/16/2007, 10:46 AM |
|
Concurrency Control:
Imagine this scenerio.
User "A" has record 100 up on his screen
User "B" also has record 100 up on his screen
User "A" makes a change by hitting the submit button which cause an update to the database
User "B" makes a change by hitting the submit button which also cause an update to the database.
User "A" just lost all of his / her changes.
Concurrency control would notify user "B: that changes were made and would refresh the form with the changes by user "A".
To me this is a very important request. More important that AJAX or other UI issues.
-Jeff
|
 |
 |
Benjamin Krajmalnik
|
| Posted: 03/19/2007, 1:59 AM |
|
Simple to do.
On the beforeshow, create a hash of the data and stor it in a session
variable.
On the OnValidate server side, retrieve the record from the database and
calc the hash. Compare it to the session variable.
You could also accomplish this in a simpler way if you have control of he
database. Make a timestamp feld which has the last modified date/time, use
it instead of the hash.
|
|
|
|
wkempees
|
| Posted: 03/19/2007, 2:17 AM |
|
I agree with Benjamin, there are several easy ways to accomplish this.
Also in the forum there is a nice discussion on this topic
http://forums.codecharge.com/posts.php?post_id=47607&s_keyword=pessimistic
But I also subscribe to this wish, it would be a great advantage if CCS
would support both "basic" optimistic and pessimistic locking
made selectable from the Project sestting or on a per form/record/grid
basis.
Implemented as extendible event.
Walter
|
|
|
|
Benjamin Krajmalnik
|
| Posted: 03/19/2007, 6:50 PM |
|
Agreed.
Simply offering a temporary solutino if this is a must for him right now.
|
|
|
|
advcomputer
Posts: 68
|
| Posted: 03/20/2007, 6:50 AM |
|
Thank you all for a solution to the issue.
I agree with Walter. This is something that should be included in the product. I cannot not see using this application for doing any type of financial transactions without some type of concurrency control.
The solutions above will work fine, however as stated this should be an out of the box option.
-Jeff
|
|
|
|
wkempees
Posts: 1679
|
| Posted: 03/20/2007, 9:18 AM |
|
Out of the box as Clarion did as of version 2
LOL
Walter
_________________
Origin: NL, T:GMT+1 (Forumtime +9)
CCS3/4.01.006 PhP, MySQL .Net/InMotion(Vista/XP, XAMPP)
if you liked this info PAYPAL me: http://donate.consultair.eu
|
|
|
|
advcomputer
Posts: 68
|
| Posted: 03/20/2007, 10:17 AM |
|
I agree..
I am a long time Clarion User!!
-Jeff
|
|
|
|
Benjamin Krajmalnik
|
| Posted: 03/22/2007, 11:12 AM |
|
Myself included :)
|
|
|
|
michaelwpayton
Posts: 18
|
| Posted: 03/23/2007, 9:03 AM |
|
In the situation below, wouldn't the "out of the box solution" proposed, simply mean that User B may lose his changes instead of User A?
Just curious, but it seems to me that any out of the box solution would have to be pretty elaborate to deal with what seems to me to be something that requires an "application specific" solution. I can just see the "CCS 4.x Concurrency Dialog" now, more complicated to "setup" than the custom code required to work around the "problem."
Having said that, it seems to me, a "do it yourself approach" has at least two advantages... 1) you can deal with situation in anyway you choose, all the way down to the field level concurrency, user prompting for "preferences," etc. and 2), most importantly, you can do it now.
Quote advcomputer:
Concurrency Control:
Imagine this scenerio.
User "A" has record 100 up on his screen
User "B" also has record 100 up on his screen
User "A" makes a change by hitting the submit button which cause an update to the database
User "B" makes a change by hitting the submit button which also cause an update to the database.
User "A" just lost all of his / her changes.
Concurrency control would notify user "B: that changes were made and would refresh the form with the changes by user "A".
To me this is a very important request. More important that AJAX or other UI issues.
-Jeff
|
|
|
|
advcomputer
Posts: 68
|
| Posted: 03/23/2007, 9:42 AM |
|
Michael,
I think the easiest way to implement the concurrency control out of the box would just mandate that any table have a date/time field with a date/time stamp.
During the update process, that date/timestamp is check buy a read to the database and if they are match, then do the write, otherwise flag an error that the data has changed and re-read the data into the form which will reflect the prior changes.
As far as doing mass - updates / deletes that is another issues, yet one that I believe also needs to be addressed.
To me, front end enhancements such as AJAX and JSON are fine, but in the end its the data that matters, not the look and feel.
-Jeff
|
|
|
|
peterr
Posts: 5971
|
| Posted: 03/24/2007, 1:26 PM |
|
Jeff,
Quote :During the update process, that date/timestamp is check buy a read to the database and if they are match, then do the write, otherwise flag an error that the data has changed and re-read the data into the form which will reflect the prior changes.
This looks somewhat complex and unreliable. Do you maybe know an enterprise software package that uses such method?
The ones I know use either "last in wins" or optimistic locking simplified to "first in wins" (mentioned by Michael). Although those systems handle multi-record updates (like used in CCS Editable Grid) and I haven't seen other truly reliable concurrency control solutions for this. Actually I'd be quite interested to review any optimistic locking method that works reliably in Web environment, doesn't end in optimistic update failure and is commonly used in enterprise systems with multi-record updates.
For single record updates the optimistic locking method described by Dave at http://forums.codecharge.com/posts.php?post_id=47607 looks really solid, is supported by CCS the way Dave implemented it, and indeed it is application specific and should be controlled by you. For example you may want to display the name of the person who updated the record earlier. Even if CCS automated it to a point you may still want to customize it, so why not just spend 30 minutes implementing what Dave recommended?
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
michaelwpayton
Posts: 18
|
| Posted: 03/25/2007, 1:11 PM |
|
Jeff,
Go for it... today, in the next 15 minutes, no lines... no waiting. That way, Yes can concentrate on providing functionality that will result in significant time savings for my developers and significant improvments in satisfaction/experience for my end-users.
:)
Quote advcomputer:
Michael,
I think the easiest way to implement the concurrency control out of the box would just mandate that any table have a date/time field with a date/time stamp.
During the update process, that date/timestamp is check buy a read to the database and if they are match, then do the write, otherwise flag an error that the data has changed and re-read the data into the form which will reflect the prior changes.
As far as doing mass - updates / deletes that is another issues, yet one that I believe also needs to be addressed.
To me, front end enhancements such as AJAX and JSON are fine, but in the end its the data that matters, not the look and feel.
-Jeff
|
|
|
|
advcomputer
Posts: 68
|
| Posted: 03/25/2007, 3:55 PM |
|
Peter,
With all due respect, there are other code generators that have the concurrency functionality right out of the box.
The software is used for generating websites that work with databases, and as such I believe as others that the data integrity is more important that UI issues.
Can I code the concurrency functionality that I want into my application, of course, but the greater question is WHY should I have to. That should be a feature that is built into the software.
Those on this forum who complain that CCS does not support AJAX and Web 2 derivitives should understand that "pretty is nice" but if the data is no good, neither is the application.
I really don't think this is a request that is out of line, as a matter of fact I would hazard a guess that the many of the people who use this software have no idea what concurrency control is, that is until they start having data issues.
Sorry for the rant, however I believe this is a fairly straight forward and valid request that should take some priority as you look to lock in the feature set for the next version.
-Jeff
|
|
|
|
Benjamin Krajmalnik
|
| Posted: 03/25/2007, 5:47 PM |
|
Peter,
Checking the contents of the record before updating to ake sure thay have
not changes is a very common, if not the predominant method.
The client application is irrelevant - whether it be web or not. The
requirements for data integrity are the same.
Record locking is not an option - even more so in a web appliction which is
stateless.
|
|
|
|
advcomputer
Posts: 68
|
| Posted: 03/25/2007, 6:13 PM |
|
Ben,
I don't think anyone could of said it better;
>>The client application is irrelevant - whether it be web or not. The
>>requirements for data integrity are the same.
-Jeff
|
|
|
|
peterr
Posts: 5971
|
| Posted: 03/25/2007, 6:43 PM |
|
Ben,
I understand that we're having this discussion only because record locking is not an option. And this is also the reason why concurrency control methods differ in Web applications. There are also articles on different concurrency solutions written by Microsoft, IBM, Sun, etc., usually differeing in recommended solutions because of the nature of the problem. I've read some of those papers and I'm familiar with some enterprise portals, but haven't really seen a solution where you'd check contents of the record before updating, rather than during updating. I may simply not be aware of which specific enterprise software uses the method of checking a record before an update, therefore I'd appreciate a pointer.
Jeff,
My response was to your specific proposed solution. If you leave the solution up to CCS then yes, it can be implemented in CCS, and based on my understanding it may be done using the method described by Dave. Therefore I ment that for now (until you see it in CCS) you can already use that method for single-record updates, and it is supported by CCS (just not automated).
And I've seen not only code generators but much higher-end software that uses simpler concurrency control which you probably wouldn't like, while here you have an option of using a solid method provided by a fellow CCS user 
Your request is also on our list and hopefully will make it into the product in not too distant future
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
peterr
Posts: 5971
|
| Posted: 03/25/2007, 6:58 PM |
|
Ben,
BTW, I probably should've explained that the concurrency issue becomes more complex with multi-record updates (and sometimes multi-table updates in larger systems).
For single record updates it may not matter too much if we check for concurrency before or during an update - the reason why I separated multi-record updates from single-record in my first post above.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
robertmann
Posts: 109
|
| Posted: 03/26/2007, 12:39 AM |
|
In our case we are responsible for implementing business logic and prefer to have more control of it. As example we need concurrency control only small percent of the time and expect to sometimes implement different concurrency handling code between applications based on database structure or according to clients feedback. Therefore, my vote would be for concurrency control at low priority.
_________________
Robert |
|
|
|
Benjamin Krajmalnik
|
| Posted: 03/26/2007, 4:16 PM |
|
Hi Peter,
The checking of the existing record buffer prior to update is used, for
example, in applictions written in Carion.
I agree with you that multi-record updates is a different item altogether,
but it depends on what you are considering a multi-record update.
Essentially, these are "first in wins" concurrency checks.
I have a set of applications, part of which are writtn i CdeCharge, and part
of which are back office automation ystems writen n Clarion running as a
service. In our case, we are dealing wih service orders, and one of the
fature which we have is the ability to "autopopulate" a specific field in
the parent by concatenating data from the child records. Of course, we want
to make sure that we do notclober data in that specific field, so I perform
concurrency control only for tht inividual ield, an everything else is "last
wins".
In multi-record update, if you look at an "edit in place" (an editable
grid), as long as each record has its unique identifier, even when making
changes to an entire set of records, you can still alert on th individual
recor's state. In the paradigm which I mentioned (checking the on-disk
buffer prior to update), you would restoe the on-screen value fo the changed
record to the on-disk state, allowig the end user to then override it.
The reasoning behind this is simple - the current state of the record may
affect the decisions affectin the data entry.
No one solution will apply to every single case, bu by and large I have
found this solution to be easy to implement and safe.
|
|
|
|
peterr
Posts: 5971
|
| Posted: 03/27/2007, 12:03 PM |
|
Thanks Ben.
These are good examples. And I'm sure that something along those lines can and will be implemented in CCS.
However, questions still remain if there can be a complete solution that some of the most demanding applications can rely on.
For example in a financial application you may have an editable grid with some JavaScript that calculates values based on other values in different rows, like in Excel. In such case you might need a transactional update that is fully reversed during an optimistic update failure.
Or you may want to perform a reversible transactional update for different reasons.
In-line editing may also not always be desired, as many applications allow editing multiple records and pressing a single "Update" button.
Proper technology solutions should cover extreme situations like division by zero, while in case of concurrency updates we'd must eliminate a chance that a record is updated by someone else after it is read/verified but before it is updated by the current user. Therefore reading records before updating them may not always be the best solution for everyone, while other simple solutions are available.
Also in extreme cases a user may enter data into editable grid, only to get frustrated after several attempts, each time getting a message that someone else also changed some of the same records.
And we could come up with additional scenarios or variants of the above.
All this should not stop CCS from having concurrency control features, only possibly shows that no single solution may apply to all situations in Web environment.
And until CCS provides any type of concurrency control, I'd hope that for simple single record maintenance someone could already implement the solution described by Dave (copy & paste) and have good control over what and how happens in their application.
Jeff,
Your wish is absolutely valid and I hope that you understand that I am not disputing it, just pointing to a temporary solution previously discussed.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
advcomputer
Posts: 68
|
| Posted: 03/27/2007, 12:28 PM |
|
Peter,
I understand exactly what you are saying and I do agree with you 100%.
-Jeff
|
|
|
|
Benjamin Krajmalnik
|
| Posted: 03/27/2007, 3:39 PM |
|
Correct,
As I mentioned there is no one solution for everything.
The only disagreement which I have with you is that what you refer as a
"solution for web" is actually the case regardless of the presentation
layer.
Ideally, you would set up transactios in the case of the financial
application with a commit or a rollback. This does not exclude the read
buffer before update scenario. However, not all database backends support
transactions, and I would bet that the majority of CCS users are using
databases which do not.
|
|
|
|
advcomputer
Posts: 68
|
| Posted: 03/29/2007, 12:14 PM |
|
Peter,
Is it safe to make the assumption that some type of concurrency control will be included in the next MAJOR release of CCS?
-Jeff
|
|
|
|
marcwolf
Posts: 361
|
| Posted: 08/09/2007, 7:33 PM |
|
With concurrency the easiest was that WE implement this is to have a Integer field in the database called Version_No
Version_No is incremented with a successful update.
When user 'A' retrieves their record - it has a Version_No of 50
When user 'B' retrieves their record - it has a Version_No of 50
When user 'B' saves their record - it has a updated Version_No of 51
When user 'A' saves their record - it has checks the Version_No against its in memory copy and sees that there is a discrepancy thus warns the user.
If multiple tables are to be updates then a Transaction can be set up and rolled back is any of the version_no do not match the memory model
Its a lot easier than using a HASH, and this functionality can be implemented as a trigger b on the UPDATE to initially check for version changes, and then to increment version changes, thus freeing the application from checking and letting the Database provice the error mechanism
Hope this helps
Take Care
Dave
_________________
' Coding Coding Coding
Keep Those Keyboards Coding.
Raw Code!!!!!!!
|
|
|
|
|
