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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
