Hi Percy, we had a similar problem with prepared statements in the past and since I saw in your bug report that the problem occurs when you are using prepared statements, then it might be related to yours. The problem was that we were creating a prepared statement, then doing an update on the database schema, and then executing the prepared statement. The second step (the update of the database schema) drops any identifiers created for keeping references to prepared statements. The answer of Fabian to this may be found at http://mail.monetdb.org/pipermail/users-list/2012-February/005417.html. Hope that helps, Babis On Tue, Dec 18, 2012 at 12:59 AM, Percy Wegmann <percy@clicksecurity.com> wrote:
Dear MonetDB Team,
We're starting to exercise our MonetDB installation more heavily now and I've run into a strange issue where I get an occasional "COMMIT: failed" message.
It seems that the conditions required to produce this are:
- Concurrently inserting into two different tables - At the same time, issuing a SELECT COUNT(*) against either of those tables
I've logged a bug with more detailed information, including a Java test case:
http://bugs.monetdb.org/show_bug.cgi?id=3210
I'm only just starting my investigation, but I suspect that COUNT(*) may be the culprit, since other selects like SELECT * don't seem to have this problem.
Does this ring any bells? Are there any special optimizations for COUNT(*) that bypass the underlying BAT and/or have side effects on some shared table somewhere that could be causing a concurrency violation?
Thanks,
--
Percy Wegmann +1 512 637 8500 ext 148
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list
_______________________________________________ users-list mailing list users-list@monetdb.org http://mail.monetdb.org/mailman/listinfo/users-list