Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of suresh.thalamati@gmail.com
 designates 64.233.184.193 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=TCpvwJ+U+IhT77EpogsLT4V5C0QyrsN7iHi6QPjoijg1qmIdqGvVKkaYRTZKtrO3TaAIckORe4mbjkBKM6KD8flqGwicria9Z5DeF94PFCdHwH6zreaZwLweHyzEtLBDAMaWn9A46IsVvbsKo8sbgDcQprKyqjPHw5X51ppD4Cw=
Message-ID: <43BEBC6A.1040902@gmail.com>
Date: Fri, 06 Jan 2006 10:52:26 -0800
From: Suresh Thalamati <suresh.thalamati@gmail.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Commented: (DERBY-239) Need a online backup feature  that
 does not block update operations   when online backup is in progress.
References: <1463889752.1136219702960.JavaMail.jira@ajax.apache.org>
 <43BC2BD7.3060300@gmail.com> <x1ofr77n6iv4.fsf@sun.com>
In-Reply-To: <x1ofr77n6iv4.fsf@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

�ystein Gr�vlen wrote:
>>>>>>"ST" == Suresh Thalamati <suresh.thalamati@gmail.com> writes:
> 
> 
>     ST> Thanks for taking time to review. My comments are in-line for some
>     ST> of the  questions, I  will respond to  the other questions  in another
>     ST> e-mail.
> 
> 
>     ST>  From you comments, one issue that we are uable to come to conclusion,
>     ST> is what to do if a backup call is issued in a transaction that already
>     ST> has a pending unlogged operations.
> 
> 
>     ST> 1) Current approach:
> 
>     ST> a) permit backup call only in  a non-idle transaction.
>     ST> b) issue a implicit commit/rollback after the backup call is done.
> 
>     ST> 2) Other approch is :
> 
>     ST> a) prevent backup  calls only when a transaction  already has executed
>     ST> unlogged operations.
> 
>     ST> b) Don't issue implicit commit/rollback after the backup
> 
>     ST> I  am ok with  either of  these approaches.  I would  like to  know if
>     ST> anyone prefers one approach over the other.
> 
> I prefer 2) for two reasons:
>     - 2a) will impact less users than 1a).  I agree that not many will
>       be hit by any of them, but it is possible that someone may think
>       of reading or recording information in the database as part of
>       doing a backup.  I think it is much less likely that someone
>       will combine an unlogged operation with backup.
>     - I think we should if possible avoid exceptions to standard
>       behavior.  Implicit commit/rollback is an exception to standard
>       behavior.  Such exceptions require specific documentation and
>       makes the product more complex to use.  Users tend not to read
>       such documentation.  1a) is less of a problem than 1b) since the
>       user will get an error if they are not aware of the problem.
>       1b) will not necessarily cause an error, but the transactional
>       behavior of an application may be different from what the user
>       thinks it is.
> 
> That said, one can not use unlimited resources in order to get the
> perfect solution.  If 2) is much more work than 1), I see the argument
> for doing 1) now and just file a JIRA issue for the better solution.
> 
>     >> * backupDatabase()
> 
>     >> - Is this the right layer for checking that the transaction is
>     >> idle and for doing rollback/commit the transaction?  Since this
>     >> is a requirement for the logic at lower layers to work
>     >> correctly, not something that is done because it is the
>     >> desirable behavior of the system procedure, I feel that this
>     >> should be done at a lower layer.
> 
>     ST> I think so, because it is better to commit/rollback at the jdbc layer
>     ST> level than  in rawstore, becuase if  we add anything  in language area
>     ST> for backup , it will surprise us.
> 
> Surprise who? In what way?
> 
>     ST> in non-idle transaction error  case backup should not commit/rollback,
>     ST> that is  why I pushed  the check to  jdbc level and also  checking for
>     ST> transaction is IDLE is already exposed to JDBC for some other code.
> 
> 
>     ST> Other  approach was to  make rawstore  throw the  error and  cacth the
>     ST> error in the jdbc layer and decide to issue commit/rollback.
> 
> I do not understand why you need to catch the error.  If I understand
> you correctly you just said that commit/rollback should not be done if
> the transaction is non-idle.
> 

My understanding is right layer to issue implicit commit/rollbacks is 
JDBC  layer than store, because the transaction backup procedure is 
using is setup from the jdbc layer.

With that assumption if  check for the transaction is IDLE is done in 
the store layer backup methods then  if it is not IDLE then that info 
has to passed back all the way to JDBC layer, so that backup procdure 
does not  issue a commit/rollback. If use the exception mechanism to 
do that , then  I have to check for Error state before issuing a 
rollback, which I normally don't like to do. That is all the reason 
behind doing check for transacion is IDLE before calling backup 
methods in store.

if implicit commit/rollbacks are not done , then I agree with you the 
right place do such checks is in the store layer.


>     ST> I generally  don't like catching  exception and then deciding  what to
>     ST> based on the SQLState, so I  decided to check for the transaction idle
>     ST> state in SystemProcedures.java
>