concurrency control for sign-off

At present, we have adopted two different schemes for the sign-off form, and also represent two different styles. The first is the Moss style and the second is the Mastery style. the Moss style does not share a sign-up area, and different signers have different signature areas. This style of the signer is fixed configuration on the node, if the counter-signer is not fixed, then the sign-up Area form permission control will appear chaos; Access style is the form of a common sign-off area, and different signers enter approval information in the same input box. When you click Approve, the approver, the approval time, and the approval comments are stored in a different table, which is displayed in the corresponding location using the table with the stitching HTML . The results are compared as follows:

1.moss style

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/6E/37/wKioL1V2t9mzFIneAADuVF8vNr0458.jpg "title=" QQ picture 20150609174648.jpg "Width=" 520 "height=" 281 "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:520px;height:281px; " alt= "Wkiol1v2t9mzfineaaduvf8vnr0458.jpg"/>

2. Tongda Style 1

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/6E/3B/wKiom1V2tlaBZ1_UAACXEqnU76U307.jpg "title=" QQ picture 20150609174821.jpg "Width=" 520 "height=" border= "0" hspace= "0" vspace= "0" style= "WIDTH:520PX;HEIGHT:72PX;" alt = "Wkiom1v2tlabz1_uaacxeqnu76u307.jpg"/>

3. Tongda Style 2

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/6E/38/wKioL1V2uELzrfBWAAFgeoJ385k208.jpg "title=" QQ picture 20150609175017.png "Width=" 520 "height=" 278 "border=" 0 "hspace=" 0 "vspace=" 0 "style=" width:520px;height:278px; " alt= "Wkiol1v2uelzrfbwaafgeoj385k208.jpg"/>

We do not need to consider concurrency control when it comes to the accessibility style, that is, to share a sign-off area, because the approval data that is formed by each approval is stored separately in a single table. For non-shared counter-checks, concurrency control is also important in addition to permission control. When a multi-person involved in the signing of the task arrived, if more than two signers opened and signed the comments, the first approval of the comments will be after the approval of the sign action coverage, the other users open the view, sign the opinion only one.

The above is an overview of the issue of sign-on concurrency control.

For concurrency problem, especially the concurrency problem of database, there is the concept of optimistic lock and pessimistic lock.

Pessimistic locking assumes that other users are trying to access or change the object you are accessing, changing the probability is very high, so in a pessimistic lock environment, before you begin to change this object to lock the object, and until you commit the changes before releasing the lock. The pessimistic flaw is that the lock-up time can be long, which can limit the access of other users for long periods of time, which means that the concurrency of pessimistic locks is not good.

Optimistic locking holds the probability that other users are trying to change the object you are changing, so the optimistic lock locks the object until you are ready to commit the changes, and does not lock when you read and change the object. It can be seen that the optimistic lock and lock time is shorter than the pessimistic lock, and the optimistic lock may obtain better concurrent access performance with larger lock granularity. But if the second user reads the object exactly before the first user commits the change, the database will find that the object has changed when he has made his own changes, so that the second user has to reread the object and make changes. This means that in an optimistic lock environment, the number of times the object is read by the concurrent user is increased.

For the particularity of the counter-sign concurrency, we adopt the optimistic lock concurrency control form, that is, in the reading and opening of the approval page without any restrictions, pending the approval of comments and submitted after the system will detect the read timestamp and the current real-time timestamp is consistent. If consistent, submit approval comments; If inconsistent, prompt the user to refresh. This idea does not match the definition of optimistic lock strictly, but it has the same effect as the realization of optimistic lock.

Here is the implementation code:

1. Defining timestamps

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/6E/37/wKioL1V2tVaQraW-AAEcY2yMp4c220.jpg "title=" QQ picture 20150609173715.jpg "alt=" Wkiol1v2tvaqraw-aaecy2ymp4c220.jpg "/>

Timestamps are in the form of serial numbers, and all of the form's timestamp definitions need to be exactly the same.

2. Judgment at time of submission

if (issign = = "1") {var Overdatedatamap;$.oaplugin.ajaxjson ({data:paras,async:false,url: "Isdataoverdate.action", Success:function (Result) {Overdatedatamap = result.overdatedatamap;if (Overdatedatamap.flag = = ' 1 ') {isDateOver = true; $.tipalert ({tipmsg: "Other countersigned users in this step have submitted approval information, please refresh the page!! ", type:0});//$.errormsgalert (" The other signed users of this step have submitted approval information, please refresh the page!!  ", Result.responsetext);}},error:function (Result) {//0 identity requires a hint of doubt or error message 1 prompts for correct information $.tipalert ({tipmsg:" error occurred! ", type:0}); }});}

3. Judgment logic

Public jsonobject isdataoverdata (flowruntime flowruntime)  {jsonobject overdatedatamap  = new jsonobject (); if (Stringutils.isnotempty (Flowruntime.gettablename ())  &&  Stringutils.isnotempty (Flowruntime.getpkvalue ())) {map<string, object> datamap =  Dymcqueryservice.executequery (Flowruntime.gettablename (),  flowruntime.getpkvalue ()); String formdata = flowruntime.getformdata (); Map<string, object> map = json2maputil.parsejson2map (Formdata); map<string, object> mainmap =  (map<string, object>) map.get ("main"); map<string, object> mainfiledsmap =  (map<string, object>) MainMap.get (" Fields "); Jsonobject newvalue = new jsonobject (); Jsonobject oldvalue = new jsonobject (); if (mainfiledsmap != null &&  datamap != null) {if (Mainfiledsmap. ContainsKey ("ZHXGSJ")  && datamap.containskey ("F_ZHXGSJ")) {if (Mainfiledsmap.get ("ZHXGSJ")  != null) {if (!mainfiledsmap.get ("ZHXGSJ"). ToString (). Equals (Datamap.get ("F_ZHXGSJ"). ToString ())) { Overdatedatamap.put ("Flag",  "1");//for (entry<string, object> entry :  Mainfiledsmap.entryset ()) {//if (Datamap.containskey ("F_"  + entry.getkey ())) {//if ( Stringutils.isnotempty (Entry.getvalue (). ToString ())  && !entry.getvalue (). ToString (). Equals ( Datamap.get ("F_"  + entry.getkey ()). ToString ()) {//newvalue.put (Entry.getkey (),  entry.getvalue () );//oldvalue.put (Entry.getkey (),  datamap.get ("F_"  + entry.getkey ()));//} else if (( Stringutils.isempty (Entry.getvalue (). toString ())  && stringutils.isnotempty (DataMap.get ("F_"  + entry.getkey ()). ToString ())   | |   (Stringutils.isnotempty (Entry.getvalue (). toString ())  && stringutils.isempty (dataMaP.get ("F_"  + entry.getkey ()). ToString ())) {//newvalue.put (Entry.getkey (),  entry.getvalue ());// Oldvalue.put (Entry.getkey (),  datamap.get ("F_"  + entry.getkey ()));//}//}else {//if ( Stringutils.isnotempty (Entry.getvalue (). toString ())) {//newvalue.put (Entry.getkey (),  entry.getvalue ());// Oldvalue.put (Entry.getkey (),  "")//}//}//}} else {overdatedatamap.put ("flag",  "0");}}  else {overdatedatamap.put ("flag",  "0");}}  else {overdatedatamap.put ("flag",  "0");} Overdatedatamap.put ("new",  newvalue), Overdatedatamap.put ("old",  oldvalue);} Else {overdatedatamap.put ("flag",  "0");}} Return overdatedatamap;}

Logical interpretation: the timestamp field in the current form data is inconsistent with the timestamp field in the real-time database, and if it is consistent, it indicates that no other counter-change data can be submitted. Commented out, the inconsistent data is removed by the property name: property value, the front end of the real-time data is merged and sent to the back side of the save.

4. Update of Timestamp:

if (Formdata.getmainfields (). ContainsKey ("F_ZHXGSJ")) {Formdata.getmainfields (). Put ("F_ZHXGSJ",      Dateutils.getnowdatetimetostr ("Yyyymmddhhmmss")); }

Through the above ideas, can effectively solve the problem of the concurrency of the signing.

This article is from the "South Lake Miner Technology Space" blog, please be sure to keep this source http://jncumter.blog.51cto.com/812546/1660158

concurrency control for sign-off