Pervasive

Hello,

I have a record that is locked during a transaction, however I'd like to keep it locked after the transaction has ended.  The documentation that I have read seems to make it quite clear that any, and all, records locked during a transaction will become unlocked when the transaction ends so I can't see how it can be done without applying my own fix-ups like manually monitoring record locks during the tran' and then re-locking once the tran' has ended.

For the sake of brevity I'll leave the explanation as to why I need to do this suffice to say though I do believe it to be a valid scenario in the context or what I'm trying to achieve.  Does anyone know of a way that this can be done?

 Many thanks.

 Actually all records locked by the session are cleared on an end transaction or abort transaction.  I do not understand the reference to "manually monitoring locks" as once you have a record lock you have the record locked until it is unlocked. 

 While in certain scenarios it may be a valid scenario there is no way to do it that I know of.  You would have to re-lock any records you need locked after the transaction ends.  The other option is to somehow change the scenario.

What I meant by "manually monitoring locks" was that I'd keep my own record of the records that I'd locked during the transaction so that I'd know which records to re-instate the locks on after the trasnaction had ended.  Many thanks for your help anyway, you've re-confirmed what the doc's say/as I suspected it would be - there isn't a striaght forward way (i.e taking advantage of built-in Btrieve functionality) of doing what I'm trying to do. 

I have read through the documentation and would ike to post a comment on this.  First off, let's review the PSQLv10 docs concerning the release of locks:

User Transactions --> var WebWorksSeeAlso = new WebWorksSeeAlso_Object(); -->if( self == top ){ window.location.replace( "../../../../index.jsp?topic=/com.pervasive.psql.doc/html/prog_gde/prog_gde-12-5.html");}

Multiple-Record Locks

A multiple-record lock allows a client to lock several records concurrently in the same file. When a client successfully locks one or more records with multiple-record locks, those locks remain in effect until the client completes one or more of the following events:

• Deletes the locked record(s).
• Explicitly unlocks the record(s) using the Unlock operation (27).
• Closes the file.
• Closes all open files by issuing a Reset operation (28).
• Obtains a file lock during an exclusive transaction.

Further, regarding transactions:

User Transactions --> var WebWorksSeeAlso = new WebWorksSeeAlso_Object(); -->if( self == top ){ window.location.replace( "../../../../index.jsp?topic=/com.pervasive.psql.doc/html/prog_gde/prog_gde-12-5.html");}

The events that cause the release of single- and multiple-record locks in concurrent transactions are similar to those for the non-transactional environment. For single, see Single-Record Locks . For multiple, see Multiple-Record Locks with the following exceptions:

• A Close operation does not release explicit record locks secured from within a concurrent transaction. With version 7.0 of the MicroKernel, you can close the file within a transaction even if a record is locked.
• An End or Abort Transaction operation releases all record locks obtained from within the transaction.

 

As expected, locking a record INSIDE a transaction and then terminating that transaction should cause this record to be unlocked.  This is completely expected.  However, I think some discussion is needed for records that are locked OUTSIDE of the transaction.

I was actually quite surprised when I did my own testing on DemoData with this.  I opened Person.MKD, read and locked the first 8 records, started a concurrent transaction, then read the ninth record inside the transaction with the expectation of modifying it. 

As soon as I read the ninth record, my locks on the other 8 records disappeared completely!  This was quite unexpected.  The documentation never mentions that starting a concurrent transaction can clear record locks.  It does explcitily state that starting an Exclusive Transaction would clear locks, as such locks would then be superfluous, so this makes sense.

This observation indicates that the behaviour of the engine is incorrect (indicating a bug in the engine), or that the documentation is incorrect (indicating a bug in the docs).

Which one SHOULD it be?  I am actually leaning towards the former.  Locking a record outside of a transaction should not necessarily be affected by the beginning of a transaction on the same file.   Will this break backward compatibility with some applications?  Perhaps.  I'd be interested in the comments of other developers using locks and concurrent transactions to see if you ever expected locks issues outside of transactions to be retained...

We are still struggling with this one. Our application currently uses single record locking strategy. We could change it to multiple locking strategy so lets assume we do this.

So, we have accessed a record and have locked it. We then want to update it but we want to do this as part of a transaction as other files are involved and we want the complete update to be atomic. We want to remain in the record and for it to remain and be locked. When we end the transaction the record naturally becomes unlocked and yes, we can lock it again, but that leaves a window of opportunity for another user to read and lock it. We dont want that to happen! Surely what we are trying to do is not unusual.

We lock a record

We want to update it as part of an transaction

We want the record to be locked throughout until we decided to unlock it.

How do we do this anyone? 

Barry  

Infodata Systems Limited, UK

 

 

BtrieveBill:

The documentation never mentions that starting a concurrent transaction can clear record locks.  It does explcitily state that starting an Exclusive Transaction would clear locks, as such locks would then be superfluous, so this makes sense.

This observation indicates that the behaviour of the engine is incorrect (indicating a bug in the engine), or that the documentation is incorrect (indicating a bug in the docs).

Which one SHOULD it be?  I am actually leaning towards the former.  Locking a record outside of a transaction should not necessarily be affected by the beginning of a transaction on the same file.   Will this break backward compatibility with some applications?  Perhaps.  I'd be interested in the comments of other developers using locks and concurrent transactions to see if you ever expected locks issues outside of transactions to be retained...

 

I need to review the code in the legacy application I'm supporting, but I fear that I may have done my last 2000i -> 10.x upgrade for the time being if this is how it's supposed to work

The software allows an operator to load and lock multiple records across multiple tables - we're talking 100s of records potentially across about 30 tables. Some of those tables might subsequently be updated, but all the records are locked to prevent anybody else trying to update them, since the update (loading a PCB design and re-engineering or re-quoting) can take several minutes. So..

1. Load the PCB version - lock all records

2. Change data

3. Save data - concurrent transaction

4. Run report

5. Change data

6. Save data...etc.

The important thing is, all of the records must remain locked and to the best of my knowledge always did in 2000i - 9.x. The only records the application needed to re-lock were those that were inserted or updated (I note the documentation does not mention updated records...maybe it is no longer required).

If I have loaded 5 quotes for a customer and locked them all via a multiple-record lock, then I update two of them in a concurrent transaction, I don't expect to have to re-lock all 5 again. If that's what is happening then either a) my application is performing a kludge and trying to quickly re-apply its locks or b) the database used to behave as I expected and at some point stopped doing so. Either way, unless I've misunderstood things, it's broken for me.
 

Interesting observation.  However, I performed the SAME test on PSQL2000i Service Pack 4, and I see the exact same results:

1. Open a File
2. Read and Lock the first record (Total Locks = 1)
   
3. Read and Lock the next four records (Total Locks = 5)
4. Begin a Concurrent Transaction (Total Locks = 5)
5. Read and Lock the next 1 record (Total Locks = 1)
6. Commit Transaction (Total Locks = 0)

As such, I can say without many doubts that this is the SAME engine logic that has been used for years.

As for affecting YOUR application, I would need more details on the exact steps being used, especially around step 3 in your list above.  Are you ONLY saving it?  Are you re-locking the record after the transaction?  You can easily tell what is happening by enabling MKDE tracing on the server as you run these steps, and by using the Pervasive Monitor from the Active Users screen to monitor the "Locks Used" counter. 

If this is the case, then yes, your app has probably been broken for years due to this issue.  This leads me towards the possibility that there is a bug in the engine, and fixing said bug will likely result in fixing several other applications, as opposed to breaking them further.  This is good news, and I think Pervasive may need to address this in some way, or at least provide a viable workaround that allows record locks to survive a BeginTransaction call.

Step 3 involves a re-lock, but only records that have been updated because it assumes the others remain locked. Which now looks like an assumption that went out with Btrieve 6.15...

I've replicated the problem here on v2000i using my application - if I load two quoted price records for a particular quote they are both locked and I cannot read either of them with the function executor when I ask for a lock at the same time. Once I save the first price in a transaction the application explicitly re-locks it but it assumes the second one is still locked - unfortunately it's not and I can now lock it via the function executor. I move onto updating the second price via my application and try to save it...status 84.

I think I've been fortunate so far that there are enough other locks further up the database hierarchy to stop this scenario happening, but it still allows somebody with a external application to update records that should be locked. Fortunately that hasn't occurred so far. I will have to update the code to re-lock all records loaded into the application for the table in question, not just the ones that have been updated.

I've always thought having to re-lock the updated record was a bug...having to re-lock the untouched ones is definitely not right. This old legacy C code doesn't need any more stuff grafted onto it!
 

I'd be curious to now set up a test environment for Btrieve 6.15 and see what THAT does...  Anyone got an old testbed Server Engine?