Re: EOAdaptorChannel problem

did you double check that your ec is locked?

On Nov 23, 2004, at 6:13 PM, Clark, Igor wrote:

> Hi there
>
> I'm using EOAdaptorChannel.deleteRowsDescribedByQualifier(EOQualifier,
> EOEntity) to delete a big pile of rows with the deletes cascading to 
> other
> tables. I'm getting my adaptorChannel by doing this:
>
>  EOEditingContext deleteEc = new EOEditingContext();
>  EOAdaptorChannel ac =
> ((EODatabaseChannel)(EOUtilities.databaseContextForModelNamed(deleteEc,
> "MyModel")).availableChannel()).adaptorChannel();
>
> Sometimes (not always, never on my desktop box and only sometimes on 
> the
> development test server) deleteRowsDescribedByQualifier throws a
> NullPointerException. If so, I catch it and use
> adaptorChannel.adaptorContext().rollbackTransaction(), but that in turn
> throws an IllegalStateException. On one occasion I also got a
> "com.webobjects.jdbcadaptor.JDBCAdaptorException: Cannot
> rollbackTransaction() while a fetch is in progress" instead of the
> IllegalStateException.
>
> Looking through the docs, it seems that "Some possible reasons for 
> failure
> are: * The adaptor channel isn't open. * The adaptor channel is in an
> invalid state (for example, it's fetching). * An error occurs in the
> database server."
>
> So, I'm taking a guess that this is happening because the 
> EOEditingContext
> I'm starting with uses the same EOObjectStoreCoordinator as other
> EOEditingContexts, and that if I just use a new 
> EOObjectStoreCoordinator in
> the initial new EOEditingContext constructor call, I might get round 
> this
> problem (leaving aside for the moment locking and integrity and all the
> other issues). Could anybody tell me if they agree or disagree? Would 
> I be
> better just constructing "DELETE FROM ..." SQL and squirting that in, 
> or
> maybe even a stored procedure would be better as it could lock on db 
> side
> etc?
>
> Thanks for any thoughts
> Igor
> _______________________________________________
> EOF mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/eof