Yes - that is a good idea -- probably a few ways to work around it… However - been using this code for years -- all the sudden pops up -- weird.
I will write back with the findings. Thanks for the help/comments. -John On Wed, Jun 12, 2013 at 2:59 PM, Longwing, Lj <[email protected]> wrote: > ** > John, > You may try creating a new 'Entry' object for the update instead of using > the same one from the Create? > > > On Wed, Jun 12, 2013 at 1:53 PM, John Sundberg < > [email protected]> wrote: > >> ** >> Good info. >> >> I referenced create_date -- since that is what we see in the log -- and >> just assumed last_mod would be the same. >> >> We are not really setting/dealing with the last_modified date/time -- >> however I suspect the Java API holds that data internally in the >> EntryObject… so when we update the EntryObject with our new field >> name/value pairs I suspect the last_modified date/time is contained in >> there and is passed along. >> >> The fundamental thing we are looking at is -- is our problem client or >> server side? >> >> With the info you gave - I suspect client side -- since no changes or >> manipulation or state info is stored server side. >> (We were sort of wondering -- since we never explicitly set the last_mod >> date in our update call. So - did not even know where that was coming from) >> >> >> We have had lots of transactions happening with this code -- however - >> have only seen this issue at this one customer and the "odd thing" was the >> 8.0 client api and 7.6.4 sp2 server. So -- sort of jumped to that area. >> Also -- replaced with 7.6.4 client -- and it did not come up again (but >> eventually did). So -- throws a wrench into that thought :) >> >> However -- the fact that nobody else said "me too" … is also helpful. >> >> Will do some more digging - and return the findings… >> >> >> -John >> >> >> On Wed, Jun 12, 2013 at 2:21 PM, Mueller, Doug <[email protected]>wrote: >> >>> ** >>> >>> First, let's review what the logic of the system is.**** >>> >>> ** ** >>> >>> Create-date is completely uninvolved in the discussion here.**** >>> >>> Modified-date is the date that is significant.**** >>> >>> ** ** >>> >>> What occurs is the following:**** >>> >>> ** ** >>> >>> A record is created. The create-date and modified-date should be >>> identical because the time of create and**** >>> >>> the time of last modify is the same at this point.**** >>> >>> ** ** >>> >>> A record may be modified, in that case, the create-date is unchanged, >>> but the modified-date is updated to**** >>> >>> reflect the new date.**** >>> >>> ** ** >>> >>> This defines the records we may be interacting with. There is no >>> difference in handling regardless of which**** >>> >>> scenario above was used.**** >>> >>> ** ** >>> >>> Now, we get to the logic around updates.**** >>> >>> ** ** >>> >>> The server gets an update request. It has no clue about when you may >>> have last touched it or when you**** >>> >>> retrieved it because there is no state information in the server. There >>> is a parameter to the API that the**** >>> >>> client program sets to indicate "when did I retrieve this record". THAT >>> value is the one the server uses in**** >>> >>> its check. It tests the value that the client gave it to see if the >>> record was changed since that date. It checks**** >>> >>> the Modified-date (C4 is the Modified-date, C3 is the Create-date) in >>> the test.**** >>> >>> ** ** >>> >>> Now, in the current version, it also tests the Last-modified-by field >>> and if it is the same user, it will not return**** >>> >>> the error (because YOU are the same user so it is not modified by a >>> "different" user). There is also ignoring**** >>> >>> of things like AR_ESCALATOR or maybe configurable ignoring of that user >>> I think so you don't get warnings**** >>> >>> about things escalations are the one who changed but I am not sure about >>> that and that is not the focus of**** >>> >>> this explanation. Now, I thought that the user test was also in 7.6.04 >>> but I cannot remember for sure what**** >>> >>> version it was added in. Again, just clarification, not critical for >>> this explanation.**** >>> >>> ** ** >>> >>> You can specify a time of 0 for when it was retrieved to indicate you >>> don't want the test for whether changed**** >>> >>> run at all and just to modify the record without testing.**** >>> >>> ** ** >>> >>> In the clients supplied by BMC, we either put 0 for that time if we >>> didn't retrieve them or we put the**** >>> >>> retrieve time that we got from the GetEntry call (there is a time of >>> retrieval in that call that we use as that**** >>> >>> ensures we are using SERVER timestamp and not client timestamp to >>> eliminate issues with clock drift between**** >>> >>> client and server).**** >>> >>> ** ** >>> >>> So, this is how everything is designed to work.**** >>> >>> ** ** >>> >>> ** ** >>> >>> Now, I have not worked directly with the API for a while and am more >>> familiar with the C API where this time**** >>> >>> value is an explicit parameter to the call. I am not sure how it is set >>> in the Java API.**** >>> >>> ** ** >>> >>> ** ** >>> >>> Scenario 1 – Is your code creating and then modifying the entry? Where >>> do you get the timestamp you are**** >>> >>> using to pass to the modify call for when the entry was "retrieved"? >>> Since you are not doing a "get" of the**** >>> >>> entry, the server cannot be giving you a server timestamp, are you using >>> a client timestamp of when you**** >>> >>> created it and if the server clock is a second or two different (ahead) >>> or the entry is created over the**** >>> >>> boundary of a second since you saved the timestamp…. You can see the >>> problem you are having.**** >>> >>> ** ** >>> >>> Scenario 2 – Is your code "getting" the entry that was created by >>> someone else and then updating it? If so,**** >>> >>> what timestamp are you using for the "retrieved" time? Are you using >>> the client time or a time returned from**** >>> >>> the "get" API call? see above for issues if it is the client time.**** >>> >>> ** ** >>> >>> Scenario 3 – Are you worried about whether the entry has been changed by >>> someone else since the time**** >>> >>> you retrieved it? If not, why aren't you setting the retrieved time to >>> 0 to eliminate the test that is done on**** >>> >>> the modify as you don't need the test run, you are just modifying >>> without checking if someone else has**** >>> >>> changed the record.**** >>> >>> ** ** >>> >>> ** ** >>> >>> We have seen absolutely no issue with any program that is using the Java >>> API correctly in this area. We have**** >>> >>> hundreds of customers using 8.0 and 8.1 programs and mid-tiers against >>> 7.6.04 (and 7.6.03 and 7.6 and 7.5**** >>> >>> and …) servers and none have reported an issue in this area. And, as >>> you have found, it isn't about the 8.1**** >>> >>> API as the issue occurs when using 7.6.04 as well.**** >>> >>> ** ** >>> >>> Now, there is always a chance that no other customer has encountered an >>> issue with any of their programs**** >>> >>> and there is something wrong in the code. It is software and you can >>> never discount things. But, the logic**** >>> >>> around this area has been stable for many releases and there have been >>> no reports of problems.**** >>> >>> ** ** >>> >>> Do you fall into one of the 3 scenarios I noted above? Should you be a >>> scenario 3?**** >>> >>> ** ** >>> >>> But, regardless, it is modified-date that is involved so create-date is >>> a distraction. And, one second off is**** >>> >>> no kind of an "off by one" error within the API/server as there is never >>> any manipulation of the date, just**** >>> >>> what date and from where is used. There is no processing of the data >>> value itself.**** >>> >>> ** ** >>> >>> ** ** >>> >>> I hope this helps explain the process that the system uses and points to >>> some ideas for solution within your**** >>> >>> code.**** >>> >>> ** ** >>> >>> Doug Mueller**** >>> >>> ** ** >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> [email protected]] *On Behalf Of *John Sundberg >>> *Sent:* Wednesday, June 12, 2013 8:51 AM >>> *To:* [email protected] >>> *Subject:* 8.0 Java API to 7.6.4 server - update records issue**** >>> >>> ** ** >>> >>> ** **** >>> >>> ** ** >>> >>> We have recently seen a sporadic issue with the 8.0 Java API against a >>> 7.6.4 server…**** >>> >>> ** ** >>> >>> The issue is -- a record is created at 2013-06-10T12:00:00 … (call this >>> 123456789)**** >>> >>> ** ** >>> >>> However **** >>> >>> ** ** >>> >>> when the record gets updated…**** >>> >>> ** ** >>> >>> The log shows **** >>> >>> ** ** >>> >>> update T1 where c4 <= 123456788 ……**** >>> >>> ** ** >>> >>> (Notice - the one second less than the create time)**** >>> >>> ** ** >>> >>> So I think what is happening is that the client library is somehow >>> losing a second (off by one error???) on the update. So - the update fails >>> with "This record has been updated since you last touched it"…**** >>> >>> ** ** >>> >>> However -- if you drop in the 7.6.4 client library -- it works fine.**** >>> >>> ** ** >>> >>> ** ** >>> >>> So … 8.0 client bug ??? or something else?**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> -John**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> -- **** >>> >>> *John Sundberg***** >>> >>> *Kinetic Data, Inc.***** >>> >>> *"Your Business. Your Process."***** >>> >>> ** ** >>> >>> 651-556-0930 I* *[email protected] **** >>> >>> www.kineticdata.com I* *community.kineticdata.com **** >>> >>> ** ** >>> >>> ** ** >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ **** >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >> >> >> -- >> >> *John Sundberg* >> Kinetic Data, Inc. >> "Your Business. Your Process." >> >> 651-556-0930 I [email protected] >> www.kineticdata.com I community.kineticdata.com >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > -- *John Sundberg* Kinetic Data, Inc. "Your Business. Your Process." 651-556-0930 I [email protected] www.kineticdata.com I community.kineticdata.com _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
