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: Question on nested transaction and SPS recompilation, anyone?
Date Thu, 10 Aug 2006 16:31:30 GMT
Just to make it clear, derby does not support any version of a "nested"
transaction which one could commit but then subsequently rollback as
part of the original transaction.   All "nested" transactions provided
by store are committed independently of the parent transaction.  These
transactions are only available internal to the server implementation 
and are not available to user applications.

Use of internal transactions in the language I believe are always used
to execute some database read/write which needs locks to get a 
consistent view, but is important to release those locks with a commit
earlier than the parent user transaction.  For instance when compiling
a query we need a consistent view of the ddl metadata which may require
locks from the database but we don't want to hold those locks until
end user transaction.

As to your specific question, it would be a bug if the language is
executing 2 related ddl updates not in the same transaction if it would
cause a bug if one part committed and one part aborted.

Yip Ng wrote:
> On 8/9/06, *Yip Ng* <yipng168@gmail.com <mailto:yipng168@gmail.com>> wrote:
>     3)  Even though the nested transaction has committed but since the
>     parent transaction is rollback, shouldn't the change in the nested
>     transaction rollback as well?  This is not what
>     I am seeing with the example given in 2). 
> I got mixed up with nested subtransaction on this one.  The internal 
> nested transaction is top level so it is independent of the parent.  
> Please ignore this question.  =)

View raw message