db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Strange assert failure, should I be worried?
Date Fri, 09 Jun 2006 06:10:20 GMT
Daniel Noll <daniel@nuix.com.au> writes:

> Hi all.
>
> Our application was reading from a BLOB stream, and allegedly
> something went wrong during the transaction (which is why we're seeing
> rollback here.)  We retry in such an event but apparently three
> failures in a row must have occurred, in which case we give up.  What
> baffles me the most is that I can't see any error with what's actually
> being displayed on-screen -- the data is all correct.
>
>> org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED setCurrentContextManager
- mismatch threads - current Thread[(thread class)$1,6,main] - cm's Thread[(thread class)$1,6,main]
>>     at org.apache.derby.iapi.services.sanity.SanityManager.THROWASSERT(SanityManager.java:150)
>>     at org.apache.derby.iapi.services.context.ContextService.setCurrentContextManager(ContextService.java:333)
>>     at org.apache.derby.impl.jdbc.TransactionResourceImpl.setupContextStack(TransactionResourceImpl.java:274)
>>     at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(EmbedConnection.java:1464)
>>     at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.java:894)
>>     at com.nuix.store.database.DatabaseWrapper.wrap(DatabaseWrapper.java:91)
>>     at com.nuix.store.binary.DatabaseBinaryStore$StoredInputStream.read(DatabaseBinaryStore.java:413)
>
> So should I be worried about this kind of error?  It's the first time
> I've ever seen one, and viewing the same data over and over doesn't
> seem to reproduce the problem.

Hmm, I don't know if you should be worried, but it worries me. I think
this must be a Derby bug of some sort, but I expect the Cloudscape
gurus in California will have more to say about it when they wake up.

The strange thing though, is that this assert is triggered at all. It claims
that 'Thread.currentThread() != cm.activeThread()'. But when it does a
toString() on those two objects, they appear to be identical:

Thread.currentThread(): Thread[(thread class)$1,6,main]
cm.activeThread():      Thread[(thread class)$1,6,main]

Can you have two different Thread objects for which toString() returns the
same String? Should the test and printout have been synchronized on
cm? Did another thread modify cm's activeThread between the ref
comparison and the toString conversion?

-- 
dt


Mime
View raw message