Performance issue databaseManager.acquireLock()

[martinh]

It seems to me that there is a performance issue when using databaseManager.acquireLock()
I see that for each foundset (with 3 records in the foundset) it takes very much time to acquire the lock:

Code: Select all

var _success = databaseManager.acquireLock(_foundset, _recordnumber) // _recordnumber = -1


I have 1500 parent records to process and 1500 times a foundset with 3 childrecords to lock and it takes a huge amount of time to process this.
In the debugger I can see a delay when acquiring the lock.
I checked it and it takes about half a second per lock.

Without the lock I do the process and this are the results:

Start: Thu May 14 14:40:30 CEST 2009
Finish: Thu May 14 14:40:45 CEST 2009


So 15 seconds to process. Now when activating the locking and I run only 1% of the records to process (so only 15 records to process), then I see the following:

Start: Thu May 14 14:45:06 CEST 2009
Finish: Thu May 14 14:45:46 CEST 2009


So 1500 records without lock cost 15 seconds and 15 records to process with lock cost 40 seconds.

Is that normal? I hope not

I tested with 3.5.9; I 'm not able to test it in 4.1.2

Martin

[jcompagner]

whats the _recordNumber exactly? is that really just -1? (so that means lock only selected record of that foundset)

or is that recordNumber constantly 1 then 2 and then 3?
So you are locking the record after each other and the process it?

can you show me the code where you do that lock?

If you want to lock the whole foundset (so 3 records) as once then you can specify -2, then the 3 records are locked in one call.

[jcompagner]

is this test you do in a real client or in the developer?

[martinh]

Johan,

value -1 means all records (see Servoy documentation)

value 0 means only the selected record

The situation is as follows:

Code: Select all

begin transaction

read record table Articles

foundset = articles_to_translations (relation, returning most of the time  3 records)

databaseManager.acquireLock(foundset, -1)

loop thru foundset to update the description field in the foundset

databaseManager.saveData()

commit transaction
release all locks

You see in the example a field recordnumber. That is because the lock is places by a standard method in my framework.
But in this case the recordnumber is always -1
And autosave is OFF

Martin

[martinh]

is this test you do in a real client or in the developer?

In developer, but I see that in real client it is also very slow. I haven't seen difference is speed between the two.

[jcompagner]

ahh my mistake about -1, was looking in our code and thats zero based not 1..

So yes -1 is lock all records of that foundset in one go.

But now looking a bit more deeper in 3.5.x code i guess that i know why it is slow for you
I think this is fixed for 4.x

What happens in 3.5 is that if you lock a complete foundset we do a flush of all the data if the lock is aquired to be sure that you work with the latest data.
This is just slow for you because all the foundsets are constantly reloading themselfs.

[martinh]

I think this is fixed for 4.x

I'm afraid it isn't (4.1.2)

I'll try to make an example next week when I can make results for both 3.5 and 4.1.2 with and without locks.

But for the moment I see that 3.5 without lock is very much faster than 4.1.2 with locks, but I'll show the results next week

Martin

[jcompagner]

ahh yes i was looking wrong

We fixed a problem with locking in 3.5.7 and 4.1.x but that results in the bad performance in the case you have there

in 4.2 we have rewritting this so that we dont have this performance issue anymore that was a result of the fix in 3.5.x and 4.1.x