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]
