target tiles still locked after commit

[Alexander Herzig]

Within a series of rasql queries, wrapped as individual transactions, i.e.

// query one
transaction.begin(read_write);
r_OQL_Query q(...);
r_oql_execute(q);
transaction.commit()

// query two
transaction.begin(read_write);
...

the tile lock seems to get stuck at one point and results in

Error: One or more of the target tiles are locked by another transaction

I've attached a minimal example.
Just extract the archive into "manuals_and_examples/examples/c++", reconfigure and build tilelockbug. rasgeo's RasdamanHelper2 class makes heavily use of the above pattern, hence rasimport and raserase virtually don't work at all.

[Alexander Herzig]

minimal bug example

[Kinga Lipskoch]

This problem is related to ticket #622.
The same happens when trying to run queries with directql.
I submitted a patch fixing that.

But, basically your code needs the connection of the lockmanager (it has an own connection) to the database.
Therefor, you can add the following after opening the database in your minimal example:

#if LOCKMANAGER_ON
    LockManager * lockManager = LockManager::Instance();
    lockManager->connect();
#endif

and the following code after closing the database:

#if LOCKMANAGER_ON
    LockManager * lockManager = LockManager::Instance();
    lockManager->disconnect();
#endif

[Dimitar Misev]

Kinga why is it necessary for the client to do this?

Can't you do the connect() (if not already connected) in the LockManager::Instance() itself?

[Kinga Lipskoch]

Actually, the connect() is not done in the Instance(), but after the server (in case of rasql) connects to the database and the disconnect() when the server calls closeDB().
So, if you have code like directql, you have to additionally call these functions.

I could put the connect in Instance(), but the only place I am sure that I can call disconnect is when the client/server closes the database. Putting the connect() in Instance() and disconnect() outside would not look nice.

[Dimitar Misev]

What about putting disconnect() in the destructor? That should work, no?

[Kinga Lipskoch]

That should theoretically work. I will have to test it.

[Dimitar Misev]

A client like rasimport should not need to do this in any case, because it's not even linked with the server's libs. So it can't even work in any case.

I believe the problem with rasimport is another, and in the ticket we are missing an email that Alex sent to the mailing list. See below:

The issue I reported only seems to come up when the rasdaman data base name deviates from its default name RASBASE, as it was the case when I first observed the tile lock error. Using the default data base name RASBASE, I don't get the error with the sample queries attached to the ticket (and rasimport/raserase work just fine).

[Dimitar Misev]

It looks like in your connect you assume a default RASBASE database, but it can be different - you can get the name from the configuration.

[Kinga Lipskoch]

Yes, you are right. I will change that. Thanks for pointing this out.

[Dimitar Misev]

But it would still be good for the connect/disconnect to reside within the Lockmanager class, otherwise we need to always remember to do this manually.

[Kinga Lipskoch]

I will try that as well and let you know.

[Kinga Lipskoch]

I submitted a patch which moves connect() to Instance() and disconnect() to the destructor.
It also solves the hardcoded database name problem. I extracted the dbId, dbUser and dbPasswd
from the configuration.

[Dimitar Misev]

Is it possible to also extract the dbPort? Piero has reported that it doesn't work with his database which is at port 5433, instead of the default one 5432.

[Kinga Lipskoch]

From configuration I can extract only dbConnectionId. This seems to contain the name, but no port.

[Dimitar Misev]

Lowering priority, non-default port issue still to be fixed.