Parallel transactions on client side broken

[Georg Semmler]

While using rasdamans c++ api I noticed the transaction management behaves strange on concurrent operations. See the attached code for a minamal test case.(I'm fully aware that this is not idomatic code, it is reduced as much as possible to trigger the bug.)
I would expect the code to result in having a collection named B with the size of 100x100 containing a double value in the database.
Instead one of the following actions happen: (The list is not exhaustiv)

• The database contains two collections, A and B
• The database contains no collection
• The database crashes:
  • With an error about invalid query syntax (e.g. terminate called after throwing an instance of 'r_Equery_execution_failed' what(): Parsing error 300 in line 1, column 31: Unexpected name in.)
  • With a memory corruption error located in (r_Ebase_dbms::r_Ebase_dbms(long const&, char const*) rasdaman/raslib/error.cc:736
  • With a internal server error (e.g terminate called recursively terminate called after throwing an instance of 'r_EGeneral[1])

From a quick lock at the source code this may be caused by unchecked access to global variables in ​http://rasdaman.org/browser/reladminif/transactionif.sc and ​http://rasdaman.org/browser/rasodmg/transaction.cc.

Beside of the observed behaviour it should be possible to create two concurrent transactions.

[Georg Semmler]

Example code to trigger the bug

[Dimitar Misev]

I believe it's mostly an issue of thread-safety in rasodmg.

[Georg Semmler]

I belive, the problem is a way bigger. Similar things could also happen in ​http://rasdaman.org/browser/reladminif/transactionif.sc for example.(It may be harder to trigger this).
As a quick fix it would be sufficient to make those two classes thread-safe.
In the long term it would be better to revisit the whole transaction system to see, if there are more similar issues and improve it to support concurrent transactions. (The example code should work without any problems and not trigger a "There is already something running" Exception at the second transaction.)

[Dimitar Misev]

It's extremely unlikely to happen in reladminif, because rasserver is never supposed to get more than one query at a time. Each query goes to a separate rasserver process.

It's completely an issue in rasodmg. We have actually made the rasodmg transaction and database classes thread-safe but the thread-safety issues go deeper in the client code unfortunately. In any case, we'll port the transaction/database fixes and try to improve on top of that.

[Dimitar Misev]

Also ticket #1215 has sample code for reproducing the issue.

[Dimitar Misev]

Duplicate of #1215

[Dimitar Misev]

Note that #1215 is now fixed. If you require thread-safety there are several places in the API where the transaction object should explicitly be specified (the C++ documentation will be updated shortly about this).