Re: Objects disappeared (was: "Static" objects in EC (was: multi-instance sync woes))
Re: Objects disappeared (was: "Static" objects in EC (was: multi-instance sync woes))
- Subject: Re: Objects disappeared (was: "Static" objects in EC (was: multi-instance sync woes))
- From: OC <email@hidden>
- Date: Tue, 02 Dec 2014 05:56:48 +0100
Chuck,
thanks a lot, but don't please let my problems spoil your vacation :)
On 2. 12. 2014, at 4:11, Chuck Hill <email@hidden> wrote:
> The list of objects to get certain operation (e.g. Insert, delete,etc) is stored separately from the EOs. I have seen cases of Insert getting replaced with Update. I think this was due to the EC not being properly locked, but an exception may have been involved too. It sounds like in your case they got into the Deleted list.
There should not be inserts, but it might be reasonable the objects were updated. Thus, if the exception and/or lock error would promote them from updates to deletes... uh-oh.
Nevertheless it is not much probable they would be updated; normally, they would be just SELECTed for display.
> That seems very odd but might be possible.
I use autolocking mostly, but there are some explicit locks with extra ECs used for background tasks -- will re-check them all, thanks!
BTW, have you ever heard of a "379. Optimistic locking: multiple transaction conflict" caused by SELECT in a serializable/pessimistic mode? I've tried to find such a scenarion in vain; is there any?
Thanks a very big lot and all the best,
OC
> ________________________________________
> From: OC <email@hidden>
> Sent: November 29, 2014 1:28:08 PM
> To: Chuck Hill
> Cc: email@hidden
> Subject: Objects disappeared (was: "Static" objects in EC (was: multi-instance sync woes))
>
> As Alice said, it gets couriouser and couriouser.
>
> On 27. 11. 2014, at 18:35, OC <email@hidden> wrote:
>> 30-odd objects simply disappeared, just like that. At one moment, I've started getting "databaseContextFailedToFetchObject" callbacks, and when I checked, the offending objects indeed did not exist -- whilst the FKs from other objects did (and caused those callbacks when relationships fired).
>>
>> Can (far as anyone knows) any combination of FrontBase locks[*] and Remote Synchronizer lead to deletion (not wrong contents, but outright disappearance) of a number of table rows?!?
>>
>> [*] note: it was in an older version of my application, which far as I know runs serialized/pessimistic
>
> Combining FB logs and all the other possible sources, well, I can't be entirely sure, but it really looks like
>
> (a) user launched a request which eventually lead to the following code, where 'dg' is an ERXDisplayGroup, 'pt' an EO of appropriate kind to which the 'formPrototype' :1 relationship indeed does lead:
>
> ===
> dg.dataSource=new EODatabaseDataSource(this.defaultEditingContext,entityName) // the auction entity, T_AUCTION table
> EOQualifier qq=new EOKeyValueQualifier('formPrototype',EOQualifier.QualifierOperatorEqual,pt)
> if (baseQualifier) qq=new EOAndQualifier([qq,baseQualifier] as NSArray) // base qualifier was nonempty
> dg.dataSource.fetchSpecification=new EOFetchSpecification(entityName,qq,null)
> dg.fetch()
> ===
>
> (b) inside the fetch, "Exception condition 379: Optimistic locking" happened (note that it has been, far as I can say, in _pessimistic_ FrontBase mode, isolation serializable):
>
> ===
> 13:55:33.433 WARN <er.extensions.appserver.ERXComponentRequestHandler>: Exception occurred while handling request:
> Exception condition 379. Optimistic locking: multiple transaction conflict detected.at com.frontbase.jdbc.FBJErrorMetaData.errorMessageAtIndex(Unknown Source)
> at com.frontbase.jdbc.FBJErrorMetaData.getExceptionChain(Unknown Source)
> at com.frontbase.jdbc.FBJConnection.checkMetaData(Unknown Source)
> at com.frontbase.jdbc.FBJConnection.commit(Unknown Source)
> at com.webobjects.jdbcadaptor.JDBCContext.commitTransaction(JDBCContext.java:452)
> at com.webobjects.jdbcadaptor.JDBCChannel._endFetch(JDBCChannel.java:417)
> at com.webobjects.jdbcadaptor.JDBCChannel.fetchRow(JDBCChannel.java:1458)
> at com.webobjects.eoaccess.EODatabaseChannel._fetchObject(EODatabaseChannel.java:321)
> at com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificationEditingContext(EODatabaseContext.java:3071)
> at er.extensions.eof.ERXDatabaseContext._objectsWithFetchSpecificationEditingContext(ERXDatabaseContext.java:68)
> at com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecification(EODatabaseContext.java:3195)
> at com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsWithFetchSpecification(EOObjectStoreCoordinator.java:488)
> at com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java:4069)
> at er.extensions.eof.ERXEC.objectsWithFetchSpecification(ERXEC.java:1308)
> at com.webobjects.eoaccess.EODatabaseDataSource.fetchObjects(EODatabaseDataSource.java:589)
> at com.webobjects.appserver.WODisplayGroup.fetch(WODisplayGroup.java:2132)
> at er.extensions.appserver.ERXDisplayGroup.fetch(ERXDisplayGroup.java:167)
> ...
> ===
>
> (c) shortly afterwards, the user did log out, which (among others) adds an audit record and saves changes, both through the session default EC. Alas, in that version, I haven't logged out whether there were changes in the EC (and which of them), but it looks like reasonably good guess there were _somehow_ stored deleteObjects, consisting precisely of those auctions the display group of the previous step would display, were the exception not happen.
>
> Far as I can say, nothing else happened meantime (but for "INFO Sending 39 changes. //log:er.extensions.remoteSynchronizer.ERXRemoteSynchronizer [ERXOSCProcessChanges]", which does not seem to be important). It seems the save generated the following SQL; T_AUCTION is the table corresponding to the display group entity:
>
> ===
> INSERT INTO "T_AUDIT"("C_UID","C_CREATION_DATE","C_KIND","C_TITLE","C_IP_ADDRESS","C_CREATOR_ID") VALUES(1003352,TIMESTAMP '2014-11-25 13:56:22.287',2,'logout: "USERNAME"','212.27.219.66',1000027);
>
> UPDATE "T_DF_FIELD" SET "C_CONTENT_DATA" = NULL WHERE "C_UID"=1000018;
> UPDATE "T_DF_FIELD" SET "C_CONTENT_DATA" = @'B00508AE7027CAB40000012E' WHERE "C_UID"=1000018;
> ... ... number of other updates which do make sense, they usually happen at logout ...
> UPDATE "T_DF_PROTOTYPE" SET "C_DF_VIEWS_DATA" = NULL WHERE "C_UID"=1000013;
> UPDATE "T_DF_PROTOTYPE" SET "C_DF_VIEWS_DATA" = @'B00508AE702809B6000002FF' WHERE "C_UID"=1000013;
>
> DELETE FROM "T_AUCTION" WHERE "C_UID"=1000076;
> ... ... 30-odd of them deleted, which DOES NOT make sense at all ...
>
> --Tran: 36747 2014-11-25-13:56:57 394910 270 270 0 181465739 0,FINServis,FINSERVIS,Europe/Prague
> ===
>
> I must admit I am completely flabbergasted.
>
> Does this make any sense to anybody? Might perhaps an extremely unlucky exception cause the ERXDisplayGroup.fetch method to delete the objects fetched? For indeed, it looks like the qualifier "qq" used above _would_ select precisely the auctions which were deleted, and none others.
>
> Note please also there are relationships betw. those auctions and other objects. There are two owning/EODeleteRuleCascade to-many relationships, whose objects (which belong to the auctions deleted) were NOT deleted. There is one EODeleteRuleDeny to-many relationship, which does contain objects related to the deleted auctions, and the deletion happened anyway: whichever strange way the deletion operations were added to the save, they self-evidently were not properly validated through the model.
>
> I've never heard of such quadruple-weird thing. Has anyone out there?
>
> Thanks a big lot,
> OC
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden