Confirmed that it occurs even with MonetDataSource.
Also tried switching to July12 SP2.

Need pointers to diagnosing it further.
Any ideas?


From: Tapomay Dey <tapomay@yahoo.com>
To: "developers-list@monetdb.org" <developers-list@monetdb.org>
Sent: Thursday, December 27, 2012 9:15 PM
Subject: Unique key constraint violation violated

Is this a known issue that you are working on? If so please give me the bug id where I would know when its fixed.

The case is as follows:
I have a table with 32 columns with unique key on 3 of them.
I am running live ETLs for putting data into monetdb. These ETLs are generating sql insert scripts.(inserts/updates/ddls)
Using JDBC and c3p0 connection pooling.
Have developed an external wrapper module to achieve master-master replication.
One common consistency check would be a count*.

Observation:
Queries are run in batches of 100 inserts clubbed into a single insert.
I do a select count(*) after each batch of 100.
After running 9100 queries the count* on one DB was 9100 but in the other was 9200.
The second DB had 100 records that were duplicates of 8901-9000.
It means when I inserted 9001 to 9100 the previous batch went into the store again with it and somehow surpassed the unique key constraint check.
I have also observed another case where count(*) gave less results than actual no. of rows in the DB.

REQUEST:
Just want to confirm if such kind of issues are part of active development.
Otherwise it would be really difficult for me to push monetdb usage into production.

Will try again with MonetDataSource instead of c3p0. But I doubt if the issues are client side or connection-related.
Plz note that the keys for which this occurs is random and thus I concluded it's not a data issue.

Regards,
Tapomay Dey.
Software Design Engg.
Sokrati Inc.
Email: tapomayATsokratiDOTcom

_______________________________________________
developers-list mailing list
developers-list@monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list