Objects disappeared (was: "Static" objects in EC (was: multi-instance sync woes))
Objects disappeared (was: "Static" objects in EC (was: multi-instance sync woes))
- Subject: Objects disappeared (was: "Static" objects in EC (was: multi-instance sync woes))
- From: OC <email@hidden>
- Date: Sat, 29 Nov 2014 19:28:08 +0100
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