• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Now to suppress excess logs at: multi-instance sync woes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Now to suppress excess logs at: multi-instance sync woes


  • Subject: Now to suppress excess logs at: multi-instance sync woes
  • From: OC <email@hidden>
  • Date: Tue, 25 Nov 2014 21:02:57 +0100

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@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Now to suppress excess logs at: multi-instance sync woes
      • From: Chuck Hill <email@hidden>
References: 
 >multi-instance sync woes (From: OC <email@hidden>)
 >Re: multi-instance sync woes (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: multi-instance sync woes
  • Next by Date: Re: Now to suppress excess logs at: multi-instance sync woes
  • Previous by thread: Re: multi-instance sync woes
  • Next by thread: Re: Now to suppress excess logs at: multi-instance sync woes
  • Index(es):
    • Date
    • Thread