We dont need to fix this because it is extremely rare and if it happens then at worst a PBE process will restart.
/AndersBj -----Original Message----- From: Neelakanta Reddy [mailto:[email protected]] Sent: den 13 augusti 2015 08:47 To: Anders Björnerstedt; Zoran Milinkovic; [email protected] Cc: [email protected] Subject: Re: [PATCH 1 of 1] imm:Decrement sqliteTransLock when BEGIN EXCLUSIVE TRANSACTION fails [#1426] Hi AndersBj, yes, the interruption may happen between if and increment. As suggested by zoran decrement sqliteTransLock in "if(sqliteTransLock != 1) { /* i.e. not 2 or 3 */". /Neel. On Thursday 13 August 2015 11:54 AM, Anders Björnerstedt wrote: > Hi > > You could *still* get interrupted between the if and the increment. > > /AndersBj > > -----Original Message----- > From: Neelakanta Reddy [mailto:[email protected]] > Sent: den 13 augusti 2015 08:00 > To: Zoran Milinkovic; Anders Björnerstedt; [email protected] > Cc: [email protected] > Subject: Re: [PATCH 1 of 1] imm:Decrement sqliteTransLock when BEGIN > EXCLUSIVE TRANSACTION fails [#1426] > > Hi zoran, > > comments below. > > /Neel. > > On Wednesday 12 August 2015 06:20 PM, Zoran Milinkovic wrote: >> Hi Neelakanta, >> >> What will happen if there is a context-switch between thread1 and thread2 >> just after "while(sqliteTransLock) {" when sqliteTransLock == 0 ? >> Then both thread1 and thread2 will pass 'while' loop and both threads will >> increase sqliteTransLock. > In this case, both thread will increment. The result will be one thread will > abort the transaction and other thread will assert when pbeClosePrepareTrans > is called. >> The likelihood that this happen is very very low, but I think that this case >> should also be covered. > yes, the likelihood is very low, but the fix could be check sqliteTransLock > before incrementing. > > if(!sqliteTransLock) > ++sqliteTransLock; /* Lock is set. */ > > >> Best regards, >> Zoran >> >> -----Original Message----- >> From: Neelakanta Reddy [mailto:[email protected]] >> Sent: Wednesday, August 12, 2015 8:48 AM >> To: Zoran Milinkovic; Anders Björnerstedt; [email protected] >> Cc: [email protected] >> Subject: Re: [PATCH 1 of 1] imm:Decrement sqliteTransLock when BEGIN >> EXCLUSIVE TRANSACTION fails [#1426] >> >> Hi zoran, >> >> In the few line above there is check to verify sqliteTransLock in " >> while(sqliteTransLock) {" . >> >> Multiple threads are present only for 2PBE case. In the 2PBE case if >> a >> thread1 is waiting for lock and got the lock released, then sqliteTransLock >> will be incremented. If in this time a context-switch happens then the >> thread2 will be spinning in sqliteTransLock. >> >> Decrementing of sqliteTransLock may not be required. >> >> /Neel. >> >> >> On Tuesday 11 August 2015 06:34 PM, Zoran Milinkovic wrote: >>> Hi Neelakanta, >>> >>> Shouldn't sqliteTransLock be also decremented few lines above in " >>> if(sqliteTransLock != 1) {" statement ? >>> >>> Thanks, >>> Zoran >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] >>> Sent: Thursday, July 30, 2015 3:47 PM >>> To: Anders Björnerstedt; Zoran Milinkovic; [email protected] >>> Cc: [email protected] >>> Subject: [PATCH 1 of 1] imm:Decrement sqliteTransLock when BEGIN >>> EXCLUSIVE TRANSACTION fails [#1426] >>> >>> osaf/libs/common/immsv/immpbe_dump.cc | 1 + >>> 1 files changed, 1 insertions(+), 0 deletions(-) >>> >>> >>> There is a chance that NFS/shared-storage may re-attach after few >>> seconds, and transaction is not yet started, so decrement the >>> sqliteTransLock in pbeBeginTrans which releases the lock >>> >>> diff --git a/osaf/libs/common/immsv/immpbe_dump.cc >>> b/osaf/libs/common/immsv/immpbe_dump.cc >>> --- a/osaf/libs/common/immsv/immpbe_dump.cc >>> +++ b/osaf/libs/common/immsv/immpbe_dump.cc >>> @@ -2909,6 +2909,7 @@ SaAisErrorT pbeBeginTrans(void* db_handl >>> LOG_ER("SQL statement ('BEGIN EXCLUSIVE TRANSACTION') >>> failed because:\n %s", >>> execErr); >>> sqlite3_free(execErr); >>> + --sqliteTransLock; >>> return SA_AIS_ERR_FAILED_OPERATION; >>> } >>> return SA_AIS_OK; ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
