[MonetDB-users] MonetDB JDBC 1.9 question
Hi,
I am getting some strange exceptions using MonetDB JDBC 1.8/1.9, and I decided to look into the code. While inspecting the code I came across these strange lines in MonetConnection.executeQuery(String[] templ, String query) method (http://dev.monetdb.org/hg/MonetDB/file/718da8ca0a1a/java/src/nl/cwi/monetdb/...).
In my case, these lines are executed for sure when doing a batch insert. So, suppose that the batch contains the following commands (as constructed by the MonetStatement.executeBatch() method):
exec 1(1, 957339737330229055); exec 1(2, 278262503670654331); exec 1(805306369, 3763943296910752235)
The lines in question take the above commands as a string, prepend a 's' character and append a ';' at the end. The resulting commands, which are written in the server's socket, are the following:
sexec 1(1, 957339737330229055); exec 1(2, 278262503670654331); exec 1(805306369, 3763943296910752235);
First of all, I am not familiar with the internals of JDBC drivers. Taking this into account, is this what it should be? From a symmetric point of view, I would assume that the correct would be the following:
sexec 1(1, 957339737330229055); sexec 1(2, 278262503670654331); sexec 1(805306369, 3763943296910752235);
That is, it should prepend a 's' character before an exec command.
Last, are these exec commands (with or without a prepending 's') specific to MonetDB? In either case, is there any documentation to get familiar with their meaning?
Thanks a lot, Babis
On 06-04-2011 16:56:17 +0300, Charalampos Nikolaou wrote:
The lines in question take the above commands as a string, prepend a 's' character and append a ';' at the end. The resulting commands, which are written in the server's socket, are the following:
sexec 1(1, 957339737330229055); exec 1(2, 278262503670654331); exec 1(805306369, 3763943296910752235);
First of all, I am not familiar with the internals of JDBC drivers. Taking this into account, is this what it should be?
Yes it exactly is what it should be.
From a symmetric point of view, I would assume that the correct would be the following:
sexec 1(1, 957339737330229055); sexec 1(2, 278262503670654331); sexec 1(805306369, 3763943296910752235);
That is, it should prepend a 's' character before an exec command.
Yes, but then you're not batching any more, which is what the command is trying to do.
Last, are these exec commands (with or without a prepending 's') specific to MonetDB? In either case, is there any documentation to get familiar with their meaning?
Yes, it is just to execute a prepared handle.
Perhaps you can give us a clue on what your problem/issue is? We might be able to just help you from what you're observing.
On Wed, Apr 6, 2011 at 5:04 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 06-04-2011 16:56:17 +0300, Charalampos Nikolaou wrote:
The lines in question take the above commands as a string, prepend a 's' character and append a ';' at the end. The resulting commands, which are written in the server's socket, are the following:
sexec 1(1, 957339737330229055); exec 1(2, 278262503670654331); exec 1(805306369, 3763943296910752235);
First of all, I am not familiar with the internals of JDBC drivers. Taking this into account, is this what it should be?
Yes it exactly is what it should be.
From a symmetric point of view, I would assume that the correct would be the following:
sexec 1(1, 957339737330229055); sexec 1(2, 278262503670654331); sexec 1(805306369, 3763943296910752235);
That is, it should prepend a 's' character before an exec command.
Yes, but then you're not batching any more, which is what the command is trying to do.
Last, are these exec commands (with or without a prepending 's') specific to MonetDB? In either case, is there any documentation to get familiar with their meaning?
Yes, it is just to execute a prepared handle.
Perhaps you can give us a clue on what your problem/issue is? We might be able to just help you from what you're observing.
Hmm, I am not very sure that I understand completely what is going on. That's why I made no point in my previous message. But, since you are asking for this, I can easily whet your appetite.
I am trying to make the Sesame RDF store work with MonetDB. When inserting some tuples to specific tables I get the following exception:
1530 [main] ERROR java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details
The next SQLExceptions is just current transaction is aborted (please ROLLBACK). So, I opted for inspecting the more simpler JDBC code in order to find something that would explain such an error. What it strucks me is that when i configure Sesame to use batches of a single statement the exceptions are gone. But again, the inserts are never persisted in the tables. Apart from this, i have also tried to change JDBC's addBatch() method to do the execute and then clearing the batch. Oddly, this works most of the times, persisting the inserts also, but there are times in which I get synchronization exceptions. While I can understand these last exceptions, I have no clue as to what is going wrong and why the behavior is different when batching with a single statement.
Any ideas?
Babis
Hi, any ideas for this?
After a lot of debugging, and because this is caused only when using Monet (other databases include MySQL and Postgres, the JDBC drivers of which have been configured to run with Connection.TRANSACTION_SERIALIZABLE, like the Monet JDBC does), I tend to believe that the exception I get is due to concurrency conflicts. Is there a way to confirm this? Having enabled the sql_debug option, I get only mal code in the server's log, which is not helpful at all.
Thanks, Babis
On Thu, Apr 7, 2011 at 1:44 PM, Charalampos Nikolaou charnik@di.uoa.gr wrote:
On Wed, Apr 6, 2011 at 5:04 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 06-04-2011 16:56:17 +0300, Charalampos Nikolaou wrote:
The lines in question take the above commands as a string, prepend a 's' character and append a ';' at the end. The resulting commands, which are written in the server's socket, are the following:
sexec 1(1, 957339737330229055); exec 1(2, 278262503670654331); exec 1(805306369, 3763943296910752235);
First of all, I am not familiar with the internals of JDBC drivers. Taking this into account, is this what it should be?
Yes it exactly is what it should be.
From a symmetric point of view, I would assume that the correct would be the following:
sexec 1(1, 957339737330229055); sexec 1(2, 278262503670654331); sexec 1(805306369, 3763943296910752235);
That is, it should prepend a 's' character before an exec command.
Yes, but then you're not batching any more, which is what the command is trying to do.
Last, are these exec commands (with or without a prepending 's') specific to MonetDB? In either case, is there any documentation to get familiar with their meaning?
Yes, it is just to execute a prepared handle.
Perhaps you can give us a clue on what your problem/issue is? We might be able to just help you from what you're observing.
Hmm, I am not very sure that I understand completely what is going on. That's why I made no point in my previous message. But, since you are asking for this, I can easily whet your appetite.
I am trying to make the Sesame RDF store work with MonetDB. When inserting some tuples to specific tables I get the following exception:
1530 [main] ERROR java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details
The next SQLExceptions is just current transaction is aborted (please ROLLBACK). So, I opted for inspecting the more simpler JDBC code in order to find something that would explain such an error. What it strucks me is that when i configure Sesame to use batches of a single statement the exceptions are gone. But again, the inserts are never persisted in the tables. Apart from this, i have also tried to change JDBC's addBatch() method to do the execute and then clearing the batch. Oddly, this works most of the times, persisting the inserts also, but there are times in which I get synchronization exceptions. While I can understand these last exceptions, I have no clue as to what is going wrong and why the behavior is different when batching with a single statement.
Any ideas?
Babis
On 07-04-2011 13:44:44 +0300, Charalampos Nikolaou wrote:
1530 [main] ERROR java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details
The next SQLExceptions is just current transaction is aborted (please ROLLBACK). So, I opted for inspecting the more simpler JDBC code in order to find something that would explain such an error. What it strucks me is that when i configure Sesame to use batches of a single
restart this with &debug=true appended to the JDBC connect URL, and look at the monet_XXXXXXXX.log file(s).
You can find the same error string there, and probably also see in what order/when it occurred. If you find multiple logfiles, then this is a good indication you may actually have multiple concurrent transactions.
On Fri, Apr 8, 2011 at 2:15 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 07-04-2011 13:44:44 +0300, Charalampos Nikolaou wrote:
1530 [main] ERROR java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details java.sql.BatchUpdateException: Error(s) occurred while executing the batch, see next SQLExceptions for details
The next SQLExceptions is just current transaction is aborted (please ROLLBACK). So, I opted for inspecting the more simpler JDBC code in order to find something that would explain such an error. What it strucks me is that when i configure Sesame to use batches of a single
restart this with &debug=true appended to the JDBC connect URL, and look at the monet_XXXXXXXX.log file(s).
You can find the same error string there, and probably also see in what order/when it occurred. If you find multiple logfiles, then this is a good indication you may actually have multiple concurrent transactions.
That was very helpful Fabian. Actually, there are 6 such log files. The next question concerns serialization. Does it suffice to grep all TX lines and sort them according to the id present next to TX? Have you got anything else to suggest in order to come to a conclusion about concurrency conflicts. In such a case, what would the solution be (actually, I have the answer, but I don't even want to spell it out)?
Thanks, Babis
On 08-04-2011 15:00:53 +0300, Charalampos Nikolaou wrote:
That was very helpful Fabian. Actually, there are 6 such log files. The next question concerns serialization. Does it suffice to grep all TX lines and sort them according to the id present next to TX? Have
yes
you got anything else to suggest in order to come to a conclusion about concurrency conflicts. In such a case, what would the solution be (actually, I have the answer, but I don't even want to spell it out)?
nothing other than carefully constructing the flow of events to see when MonetDB thinks a concurrency conflict occurs, then to verify if it is correct or not
Hi,
I have gained a great experience by looking into the jdbc logs, but unfortunately I haven't come to a conclusion yet. I need information about the state of the mserver5 as well. For example, by looking only the jdbc logs it is not clear when a transaction is commited. Concerning the different monet_*.log files created by jdbc, should I suppose that belong to a different jdbc thread, different transaction, or something else?
And one last question: what are the debug options for mserver5? I found this link (http://monetdb.cwi.nl/MonetDB4-compiled/etc/MonetDB.conf) which states a bunch of gdk_debug options some of them still valid in monetdb5, but the one that I am interested in does not produce any output (transaction management). Is there any alternative value/property for transaction management? I am also aware of the sql_debug (valid values 0/1). Other?
Thanks, Babis
On Fri, Apr 8, 2011 at 3:03 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 08-04-2011 15:00:53 +0300, Charalampos Nikolaou wrote:
That was very helpful Fabian. Actually, there are 6 such log files. The next question concerns serialization. Does it suffice to grep all TX lines and sort them according to the id present next to TX? Have
yes
you got anything else to suggest in order to come to a conclusion about concurrency conflicts. In such a case, what would the solution be (actually, I have the answer, but I don't even want to spell it out)?
nothing other than carefully constructing the flow of events to see when MonetDB thinks a concurrency conflict occurs, then to verify if it is correct or not
Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
If you are running with parallel threads against a single MonetDB server then you should be aware that the transaction safety is guaranteed, but that the optimistic concurrency scheme may create more conflicts (transaction failures) then you would encounter in lock-based transaction managers. Such failures are reported by jdbc, so check for them, if you hadn't done so.
regards, Martin
On 4/9/11 4:54 PM, Charalampos Nikolaou wrote:
Hi,
I have gained a great experience by looking into the jdbc logs, but unfortunately I haven't come to a conclusion yet. I need information about the state of the mserver5 as well. For example, by looking only the jdbc logs it is not clear when a transaction is commited. Concerning the different monet_*.log files created by jdbc, should I suppose that belong to a different jdbc thread, different transaction, or something else?
And one last question: what are the debug options for mserver5? I found this link (http://monetdb.cwi.nl/MonetDB4-compiled/etc/MonetDB.conf) which states a bunch of gdk_debug options some of them still valid in monetdb5, but the one that I am interested in does not produce any output (transaction management). Is there any alternative value/property for transaction management? I am also aware of the sql_debug (valid values 0/1). Other?
Thanks, Babis
On Fri, Apr 8, 2011 at 3:03 PM, Fabian GroffenFabian.Groffen@cwi.nl wrote:
On 08-04-2011 15:00:53 +0300, Charalampos Nikolaou wrote:
That was very helpful Fabian. Actually, there are 6 such log files. The next question concerns serialization. Does it suffice to grep all TX lines and sort them according to the id present next to TX? Have
yes
you got anything else to suggest in order to come to a conclusion about concurrency conflicts. In such a case, what would the solution be (actually, I have the answer, but I don't even want to spell it out)?
nothing other than carefully constructing the flow of events to see when MonetDB thinks a concurrency conflict occurs, then to verify if it is correct or not
Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 09-04-2011 17:54:10 +0300, Charalampos Nikolaou wrote:
I have gained a great experience by looking into the jdbc logs, but unfortunately I haven't come to a conclusion yet. I need information about the state of the mserver5 as well. For example, by looking only the jdbc logs it is not clear when a transaction is commited.
When a "statement" or "batch" is executed.
Concerning the different monet_*.log files created by jdbc, should I suppose that belong to a different jdbc thread, different transaction, or something else?
A different connection to the server.
And one last question: what are the debug options for mserver5? I found this link (http://monetdb.cwi.nl/MonetDB4-compiled/etc/MonetDB.conf) which states a bunch of gdk_debug options some of them still valid in monetdb5, but the one that I am interested in does not produce any output (transaction management). Is there any alternative value/property for transaction management? I am also aware of the sql_debug (valid values 0/1). Other?
There are no debug options in the server that would give you any insight you're looking for on transaction validity.
Here I am again,
I have made all my interactions with the server to be auto-committed. Still I get a "current transaction abort (please rollback)" error message without understanding the reason. I have looked into the jdbc logs very carefully, I have also serialized all 6 connections, but nothing seem to be wrong. The interaction with the server is attached in sql.log (contains only the sql commands as if there was a single connection executing them). The serialized logs are attached in serial.log (there are comments about the time a connection starts/continues/ends or giving execution to another connection, and all timestamps generated from jdbc have been replaced by 1, 2, 3, and so on for readability purposes. All lines starting with % or [ have been omitted; the complete logs for each connection are also attached in monet_*.log files. All files are attached in a .zip archive.
If you can see something that I can't please report it.
Thanks a lot, Babis
On Sat, Apr 9, 2011 at 9:59 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 09-04-2011 17:54:10 +0300, Charalampos Nikolaou wrote:
I have gained a great experience by looking into the jdbc logs, but unfortunately I haven't come to a conclusion yet. I need information about the state of the mserver5 as well. For example, by looking only the jdbc logs it is not clear when a transaction is commited.
When a "statement" or "batch" is executed.
Concerning the different monet_*.log files created by jdbc, should I suppose that belong to a different jdbc thread, different transaction, or something else?
A different connection to the server.
And one last question: what are the debug options for mserver5? I found this link (http://monetdb.cwi.nl/MonetDB4-compiled/etc/MonetDB.conf) which states a bunch of gdk_debug options some of them still valid in monetdb5, but the one that I am interested in does not produce any output (transaction management). Is there any alternative value/property for transaction management? I am also aware of the sql_debug (valid values 0/1). Other?
There are no debug options in the server that would give you any insight you're looking for on transaction validity.
Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
I'm new using MonetDB, I have a question:
What is the best way to add hundreds or thousands of rows per second on a table MonetDB?
Thanks in advance.
I'm new using MonetDB, I have a question:
What is the best way to add hundreds or thousands of rows per second on a table MonetDB?
Thanks in advance.
Hi,
I am also new to MonetDB, but COPY .. INTO is probably your best bet.
http://www.monetdb.org/Documentation/Manuals/SQLreference/CopyInto
It is quite fast, and you can use a database dump to see example of the syntax / try it out:
http://www.monetdb.org/Documentation/UserGuide/DumpRestore
Cheers, - Philippe
On May 23, 2011, at 4:54 PM, julio Puebla wrote:
I'm new using MonetDB, I have a question:
What is the best way to add hundreds or thousands of rows per second on a table MonetDB?
Thanks in advance.
vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1__________________________________________... MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
You might consider the SQL COPY INTO statement. On 5/24/11 1:48 AM, julio Puebla wrote:
I'm new using MonetDB, I have a question:
What is the best way to add hundreds or thousands of rows per second on a table MonetDB?
Thanks in advance.
vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 04/11/2011 06:58 PM, Charalampos Nikolaou wrote:
Hi, any progress on this? Because the discussion has been dormant for about a month I outline the problem:
I have some threads querying MonetDB and I get the error "current transaction abort (please rollback)". All interactions with the server are configured to be auto-committed. The strange thing is that the same code is running on top of PostGIS, with the JDBC configured to use the TRANSACTION_SERIALIZABLE policy (i.e., the same that the JDBC of MonetDB supports) and there is no problem at all.
I acknowledge that sometimes discovering race conditions is a rather difficult task, but from my side and by inspection of the JDBC logs that I have uploaded I cannot understand why the transaction is aborted. At least, the reason is not obvious to me just by inspection of the JDBC logs. Maybe the reason lies on the server side, but definitely I cannot tell for sure.
Any ideas?
Thanks, Babis
Here I have another more interesting scenario in which all go well, without transaction aborts, but some inserts have failed to be persisted in the database. All interactions are again auto-commited.
The same scenario has been run successfully on Postgres.
I attach an html file with the jdbc logs organized in a way helpful to understand concurrent execution of threads using different connections. This is done using a table each column of which is associated with a different connection. Again the timestamps have been mapped to natural numbers for readability purposes. At the end of each column the problems are summarized.
Any ideas as to what the source of the problem may be?
Thanks, Babis
Here I am again,
I have made all my interactions with the server to be auto-committed. Still I get a "current transaction abort (please rollback)" error message without understanding the reason. I have looked into the jdbc logs very carefully, I have also serialized all 6 connections, but nothing seem to be wrong. The interaction with the server is attached in sql.log (contains only the sql commands as if there was a single connection executing them). The serialized logs are attached in serial.log (there are comments about the time a connection starts/continues/ends or giving execution to another connection, and all timestamps generated from jdbc have been replaced by 1, 2, 3, and so on for readability purposes. All lines starting with % or [ have been omitted; the complete logs for each connection are also attached in monet_*.log files. All files are attached in a .zip archive.
If you can see something that I can't please report it.
Thanks a lot, Babis
Could this http://sourceforge.net/mailarchive/message.php?msg_id=28878164 also be the to the issue reported here?
from the link above: " Here is the problem. If you perform a schema update/change, MonetDB releases all prepared handles, because they possibly are no longer correct. You need to re-execute your prepare command. "
?
Stefan
On Mon, Apr 11, 2011 at 06:58:02PM +0300, Charalampos Nikolaou wrote:
Hi, any hint on this? Because this discussion has been dormant
Here I am again,
I have made all my interactions with the server to be auto-committed. Still I get a "current transaction abort (please rollback)" error message without understanding the reason. I have looked into the jdbc logs very carefully, I have also serialized all 6 connections, but nothing seem to be wrong. The interaction with the server is attached in sql.log (contains only the sql commands as if there was a single connection executing them). The serialized logs are attached in serial.log (there are comments about the time a connection starts/continues/ends or giving execution to another connection, and all timestamps generated from jdbc have been replaced by 1, 2, 3, and so on for readability purposes. All lines starting with % or [ have been omitted; the complete logs for each connection are also attached in monet_*.log files. All files are attached in a .zip archive.
If you can see something that I can't please report it.
Thanks a lot, Babis
vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Hi Stefan,
yes it might be, but as far as I remember in my case there was no exception at all. Right now it is almost impossible to reproduce the above scenario, but I will have a closure look.
Thanks for bringing it up again, Babis
On Thu, Feb 23, 2012 at 5:20 PM, Stefan Manegold Stefan.Manegold@cwi.nl wrote:
Could this http://sourceforge.net/mailarchive/message.php?msg_id=28878164 also be the to the issue reported here?
from the link above: " Here is the problem. If you perform a schema update/change, MonetDB releases all prepared handles, because they possibly are no longer correct. You need to re-execute your prepare command. "
?
Stefan
On Mon, Apr 11, 2011 at 06:58:02PM +0300, Charalampos Nikolaou wrote:
Hi, any hint on this? Because this discussion has been dormant
Here I am again,
I have made all my interactions with the server to be auto-committed. Still I get a "current transaction abort (please rollback)" error message without understanding the reason. I have looked into the jdbc logs very carefully, I have also serialized all 6 connections, but nothing seem to be wrong. The interaction with the server is attached in sql.log (contains only the sql commands as if there was a single connection executing them). The serialized logs are attached in serial.log (there are comments about the time a connection starts/continues/ends or giving execution to another connection, and all timestamps generated from jdbc have been replaced by 1, 2, 3, and so on for readability purposes. All lines starting with % or [ have been omitted; the complete logs for each connection are also attached in monet_*.log files. All files are attached in a .zip archive.
If you can see something that I can't please report it.
Thanks a lot, Babis
vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
-- | Stefan.Manegold @ CWI.nl | DB Architectures (INS1) | | http://CWI.nl/~manegold/ | Science Park 123 (L321) | | Tel.: +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
Yes, it IMHO is:
an extract of you serial log reveals:
======== [...] CREATE INDEX hash_values_value_idx ON hash_values (value); PREPARE SELECT MAX(id), MOD((id >> 28) + 16, 16) AS grp FROM hash_values GROUP BY grp; -- 1st PREPARE -> ID "0" exec 0(); CREATE TABLE namespace_prefixes ( prefix VARCHAR(127), namespace TEXT NOT NULL ); -- schema update -> deletes ALL PREPAREd statements [...] PREPARE SELECT id, value FROM hash_values WHERE value IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?); -- 1st (after "reset") PREPARE -> ID "0" exec 0(14329055, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); PREPARE INSERT INTO hash_values (id, value) VALUES (?, ?); -- 2nd PREPARE -> ID "1" PREPARE INSERT INTO uri_values (id, value) VALUES (?, ?); -- 4rd PREPARE -> ID "2" exec 0(14154331, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); exec 0(142752235, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL); PREPARE INSERT INTO label_values (id, value) VALUES (?, ?); -- 4th PREPARE -> ID "3" PREPARE INSERT INTO namespace_prefixes (prefix, namespace) VALUES (?, ?); -- 5th PREPARE -> ID "4" exec 2(NULL, 'http://www.recshop.fake/cd#'); PREPARE UPDATE namespace_prefixes SET prefix = ? WHERE namespace = ?; -- 6th PREPARE -> ID "5" exec 3('cd', 'http://www.recshop.fake/cd#'); PREPARE INSERT INTO namespace_prefixes (prefix, namespace) VALUES (?, ?); -- 7th PREPARE -> ID "6" exec 4(NULL, 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'); PREPARE UPDATE namespace_prefixes SET prefix = ? WHERE namespace = ?; -- 8th PREPARE -> ID "7" exec 5('rdf', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'); CREATE TABLE triples ( ctx INTEGER NOT NULL, subj INTEGER NOT NULL, pred INTEGER NOT NULL, obj INTEGER NOT NULL, expl BOOL NOT NULL, interval_start TIMESTAMP DEFAULT NULL, interval_end TIMESTAMP DEFAULT NULL ); -- schema update -> deletes ALL PREPAREd statements [...] PREPARE INSERT INTO triples (ctx, subj, pred, obj, expl) VALUES (?, ?, ?, ?, ?); -- 1st (after "reset") PREPARE -> ID "0" exec 0(0, 1, 2, 805306369, true); exec 1(1, 14329055); -- ! ^ no such prepared statement ! exec 1(2, 14154331); exec 1(805306369, 142752235); ========
Stefan
On Thu, Feb 23, 2012 at 04:20:46PM +0100, Stefan Manegold wrote:
Could this http://sourceforge.net/mailarchive/message.php?msg_id=28878164 also be the to the issue reported here?
from the link above: " Here is the problem. If you perform a schema update/change, MonetDB releases all prepared handles, because they possibly are no longer correct. You need to re-execute your prepare command. "
?
Stefan
On Mon, Apr 11, 2011 at 06:58:02PM +0300, Charalampos Nikolaou wrote:
Hi, any hint on this? Because this discussion has been dormant
Here I am again,
I have made all my interactions with the server to be auto-committed. Still I get a "current transaction abort (please rollback)" error message without understanding the reason. I have looked into the jdbc logs very carefully, I have also serialized all 6 connections, but nothing seem to be wrong. The interaction with the server is attached in sql.log (contains only the sql commands as if there was a single connection executing them). The serialized logs are attached in serial.log (there are comments about the time a connection starts/continues/ends or giving execution to another connection, and all timestamps generated from jdbc have been replaced by 1, 2, 3, and so on for readability purposes. All lines starting with % or [ have been omitted; the complete logs for each connection are also attached in monet_*.log files. All files are attached in a .zip archive.
If you can see something that I can't please report it.
Thanks a lot, Babis
vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
-- | Stefan.Manegold @ CWI.nl | DB Architectures (INS1) | | http://CWI.nl/~manegold/ | Science Park 123 (L321) | | Tel.: +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 23-02-2012 18:13:16 +0200, Charalampos Nikolaou wrote:
yes it might be, but as far as I remember in my case there was no exception at all. Right now it is almost impossible to reproduce the above scenario, but I will have a closure look.
A bug that pre-Dec2011 servers had was that prepare handles were "silently overwritten". You might have hit that problem. But that's just pure guesswork.
Hmm, thanks for this clarification Fabian, because back then (August I think) I am pretty sure I wasn't taking any exceptions at all, except that insertions were not persisted even though the respective queries had been executed (you can confirm this by inspecting the last html file I had attached then -- the html has a table each column of which corresponds to a separate jdbc connection; when the server moves from one connection to another, a new row is created in that table).
Regards, Babis
On Thu, Feb 23, 2012 at 9:17 PM, Fabian Groffen Fabian.Groffen@cwi.nl wrote:
On 23-02-2012 18:13:16 +0200, Charalampos Nikolaou wrote:
yes it might be, but as far as I remember in my case there was no exception at all. Right now it is almost impossible to reproduce the above scenario, but I will have a closure look.
A bug that pre-Dec2011 servers had was that prepare handles were "silently overwritten". You might have hit that problem. But that's just pure guesswork.
Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
participants (6)
-
Charalampos Nikolaou -
Fabian Groffen -
julio Puebla -
Martin Kersten -
Philippe Hanrigou -
Stefan Manegold