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 <doug_muel...@bmc.com> 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: > arslist@ARSLIST.ORG] *On Behalf Of *John Sundberg > *Sent:* Wednesday, June 12, 2013 8:51 AM > *To:* arslist@ARSLIST.ORG > *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* *john.sundb...@kineticdata.com **** > > 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 john.sundb...@kineticdata.com 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"
