db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: org.apache.derby.impl.store.raw.xact.Xact Destroy BUG?
Date Thu, 11 May 2006 17:54:00 GMT
Can you add anything about what your approach with Derby will be?  I
suggest you search this list as there have been recent discussions about
replication schemes appropriate to Derby.

I continue to think that starting at the Raw store level is the wrong
place as the system is not designed to give a user level look at data
at that point.  And there are no open interfaces supported.

One suggestion was using an open source product which captured the info
at the jdbc level.  Also others have used triggers to provide the
necessary information.

Can you make it clearer when you expect to receive an "ABORT" - for
instance maybe only when user application either issues an abort or
recieves a specific SQLState error?  Derby generates a lot of internal
aborts which either may never be seen by the user, or may be translated
to other errors like a duplicate key error, or syntax error.

Susana Guedes wrote:
> Hi everyone,
> 
> I am working as a researcher in a European Investigation Project named 
> GORDA - http://gorda.di.uminho.pt/
> The goal is to make a patch to Derby to provide in-core replication 
> mechanisms.
> Currently i am reflecting the transaction context indicating a 
> transaction Begin / Commit / Abort / Close
> 
> I think i found a bug in the method destroy() of 
> org.apache.derby.impl.store.raw.xact.Xact class.
> 
> In this method you do:
> if(state!=CLOSED){abort();}
> close();
> 
> I think that you should be doing
> if(state!=IDLE){abort();}
> close();
> 
> Is this really a bug?  In my case the replicator is receiving a lot of 
> ABORT notifications when he should only be receivig the CLOSE notification.
> 
> 
> Regards
> Susana
> 
> 


Mime
View raw message