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