Chuck, thanks a lot, but don't please let my problems spoil your vacation :)
On 2. 12. 2014, at 4:11, Chuck Hill <[email protected]> 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 protected]> > Sent: November 29, 2014 1:28:08 PM > To: Chuck Hill > Cc: [email protected] > 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 protected]> 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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
