Chuck,
On 25. 11. 2014, at 21:45, Chuck Hill <[email protected]> wrote:
> That comes from Wonder, that message is logged from either
> ERXEOAccessUtilities or ERXTolerantSaver. It is trying to process the thrown
> exception and not finding some important pieces of data. I don’t know why
> they would be missing. That is the first thing that I would investigate.
Perhaps, but at my level it seems right (esp. the exception _I_ am getting
always contains EOFailedAdaptorOperationKey).
When/if I have more time, I'll try, but at the moment I've got other problems,
will write in a moment in another message.
> You are using the FrontBase plugin framework, right?
Yup.
> As it is coming from a log4j logger in wonder, you could set the threshold to
> FATAL to prevent this logging.
Thanks, it did help indeed.
> On 2014-11-25, 12:02 PM, "OC" wrote:
>
> Let me thank you again -- it seems it works great!
>
> One small glitch though: before I get the exception in catch() and can
> process it, someone up there (looks like the frontbase JDBC adaptor) logs out
> heaps and heaps of things, which start with
>
> ===
> 20:56:06.567 ERROR Missing EOFailedAdaptorOperationKey or
> EOFailedDatabaseOperationKey in
> com.webobjects.eoaccess.EOGeneralAdaptorException: EvaluateExpression failed:
> <com.webobjects.jdbcadaptor.FrontbasePlugIn$FrontbaseExpression: "INSERT INTO
> "T_DF_FIELD"("C_TEMPLATE_ID", "C_CONTENT_DATA", "C_TYPE", "C_UID", "C_TITLE",
> "C_DESCRIPTION", "C_LOCKED", "C_ORDER", "C_CREATION_DATE", "C_IDENTIFIER")
> VALUES (100, NULL, 'DFListField', 119, 'EditorsUpravují', 'Selected user
> roles can create/edit users through this prototypeVybrané uživatelské role
> mohou upravovat uživatele podle tohoto vzoru', NULL, 9, TIMESTAMP '2014-11-25
> 20:56:03.358', 'userRoleEditors')" withBindings: >:
> Next exception:SQL State:23 subclass = 00 -- error code: 358 --
> msg: Exception condition 358. Integrity constraint violation (PRIMARY KEY,
> T_DF_FIELD._C70(C_UID=119)).
> Next exception:SQL State:40 subclass = 00 -- error code: 363 --
> msg: Exception condition 363. Transaction rollback.: {EOAdaptorOperationsKey
> = ( {_exception = Exception condition 358. Integrity constraint violation
> (PRIMARY KEY, T_DF_FIELD._C70(C_UID=119)).at
> com.frontbase.jdbc.FBJErrorMetaData.errorMessageAtIndex(FBJErrorMetaData.java:162)
> at
> com.frontbase.jdbc.FBJErrorMetaData.getExceptionChain(FBJErrorMetaData.java:194)
> at com.frontbase.jdbc.FBJStatement.checkMetaData(FBJStatement.java:472)
> at com.frontbase.jdbc.FBJStatement.execute(FBJStatement.java:185)
> at
> com.webobjects.jdbcadaptor.JDBCChannel._bindInputVariablesWithBindingsAndExecute(JDBCChannel.java:272)
> at
> com.webobjects.jdbcadaptor.JDBCChannel._evaluateExpression(JDBCChannel.java:337)
> ...
> ...
> ===
>
> and go on for a long long time.
>
> Is there a way to suppress this log? Not only it clutters the log files, but
> it's long enough to make the application perceptibly slower.
>
> Thanks a lot,
> OC
>
> On 25. 11. 2014, at 19:11, Chuck Hill <[email protected]> wrote:
>
> (b) concurrent inserts
> This problem is caused by my using fixed PKs (though if I did not, I might be
> getting duplicated EOs instead). If two instances try to insert a new EO with
> the same PK, I'm (naturally) getting a constraint PK violation exception from
> the database.
> And I can't find a way to solve it :(
> I can (and do) try to fetch the offending object -- and since the other
> instance committed meantime, I get it all right:
> ===
> ... code as above ...
> if (ocs_is_primary_key_constraint(exception) &&
> adaptorOp.adaptorOperator()==EODatabaseOperation.AdaptorInsertOperator) {
> NSArray pka=entity.primaryKeyAttributes()
> EOQualifier
> pkq=ERXEOAccessUtilities.qualifierFromAttributes(pka,adaptorOp.changedValues())
> // contains the PK
> EOFetchSpecification fs=new EOFetchSpecification(entityName,pkq,null)
> fs.setRefreshesRefetchedObjects(YES)
> NSArray objs=ec.objectsWithFetchSpecification(fs)
> if (objs.count()==1) {
> // OK, my code does get here, the object inserted by other instance is
> fetched all right. But what now?!?
> ???
> _saveTolerantlyChangesInEC(ec) // let's try again
> ... ...
> ===
> What to do at the ??? place? If I do nothing, the insert operation stays in
> EC and fails again.
> I've tried to remove the newly added object from ec.insertedObjects.
> Strangely enough it did work (i.e., it has been removed -- self evidently,
> internally insertedObjects is a mutable array), but did not help -- this way
> led to the dreaded "rowDiffsForAttributes: snapshot in
> com.webobjects.eoaccess.EODatabaseOperation {_dbSnapshot = {}; ..."
> exceptions.
> Currently I am recording the PK and entity, and in my
> databaseContextWillOrderAdaptorOperations I do not add adaptor operation for
> such an insert. This seems to sort of work, but is TERRIBLY convoluted --
> there must be a better solution?
> Set the relationships for any other objects into the EC to the one fetched,
> not the one just created and then ec.deleteObject(dupicate object))
>
>
_______________________________________________
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]
