Øystein Grøvlen wrote:
"ST" == Suresh Thalamati <[EMAIL PROTECTED]> 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
