db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Mason" <b.ma...@adinstruments.com>
Subject RE: Rolling back a transaction leads to an inconsistent state
Date Thu, 29 Mar 2012 20:49:37 GMT
> -----Original Message-----
> From: Knut Anders Hatlen [mailto:knut.hatlen@oracle.com] 
> Sent: Thursday, 29 March 2012 21:58
> To: Derby Discussion
> Subject: Re: Rolling back a transaction leads to an inconsistent state
> 
> "Brett Mason" <b.mason@adinstruments.com> writes:
> 
> > Hi there,
> >
> > I think I have encountered a bug where rolling back a 
> transaction can leave
> > a table in an inconsistent state if the table has been 
> previously altered
> > through the addition of new columns. It appears that if 
> newly added columns
> > have not been changed from their default value, then when a 
> transaction
> > which sets new values for these columns is rolled back the 
> new columns are
> > not restored to their previous values.
> >
> > I have attached an ij script with fairly minimal steps to 
> reproduce the
> > problem on Derby 10.6.2.0 and 10.8.2.2 (Win7 x64, Sun 
> 32-bit JRE 1.6.0.26).
> > Expected and observed output is below.
> >
> > There doesn't appear to be an existing bug for this issue. 
> Should I go ahead
> > and file one in JIRA?
> 
> Hi Brett,
> 
> This certainly looks like a bug. Please file a report in JIRA 
> and upload
> the repro script there so it can be investigated.
> 
> > Can anyone suggest a workaround? Running 
> SYSCS_UTIL.SYSCS_COMPRESS_TABLE on
> > the table after it is altered seems to avoid the problem 
> but I'm concerned
> > it may be just masking the issue.
> 
> That sounds like a useful observation that it would be helpful to
> mention in the JIRA report. SYSCS_COMPRESS_TABLE creates a fresh
> conglomerate for the table and its indexes, and might be able to fix
> some inconsistencies in that process. But these inconsistencies should
> of course not have been there in the first place.
> 
> Thanks,
> 
> -- 
> Knut Anders

Thanks Knut, reported as DERBY-5679.

Another possible workaround which appears to work is explicitly setting
default values for the columns after they are created. For example: UPDATE
TABLE1 SET TIMESTAMP1 = NULL WHERE TIMESTAMP1 IS NULL . 

Cheers,
Brett.


Mime
View raw message