VirtualDatabaseWorkerThread reset() doesn't reset isReadOnly
------------------------------------------------------------

         Key: SEQUOIA-1053
         URL: https://forge.continuent.org/jira/browse/SEQUOIA-1053
     Project: Sequoia
        Type: Bug

  Components: Core  
    Versions: Sequoia 2.10.8    
    Reporter: Chris Ekberg


If a connection to a VirtualDatabaseWorkerThread sets readonly=true (common 
thing with Hibernate) and then the worker thread is reused for another 
statement/transaction, reset() is called, but isReadOnly is not reset so the 
connection is still marked as readonly.

This causes problems with the RecoveryLog - if a backend is offline and another 
backend takes traffic like this (readonly transaction and then new transaction 
with an update, for example), the NotifyCompletion tasks for the update 
statement will be marked as readonly, and the offline backend's recovery log 
will not be updated from being marked 'E' (executing) to 'S' (successful 
completion).  If you then attempt to bring the offline backend online, the 
RecoverThread will spin forever trying to recover this statement, since it sees 
it is still executing and will wait for it to finish, but it is never actually 
executed.  Worse yet, this can happen while the entire VDB is suspended, so all 
traffic to all backends of this database will be stopped.

Simple fix:  add "isReadOnly = false;" to reset() function.




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia

Reply via email to