> On Dec 2, 2014, at 12:02 PM, OC <[email protected]> wrote: > > 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]
