ArcadeDB use ConcurrentModificationException in a weird way. It throw that exception when a page is modified by somebody else, but who care about pages?
ConcurrentModificationException in all database represent that the record I need to commit was modified by somebody else, so I should decide what to do, overwrite the modified record o ask the user. That's the deal.
But with pages that is not true. The database throw that exception even when the data is ok and there no conflict and it seems there is no way to resolve what happens. A blind retry is not an option because I could overwrite something important, and ask the user in a heavy concurrent environment is not practical because we never end a simple save.
We have about 1254 user so every bucket change at every second. With the average creation of 873 case per morning day, every new page is modified by someone else, and we have more than a half of millon active cases that are updated at the same time.
CME should be launched only if the involved record are modified like was in OrientDB or any other database.
Actually in all our concurrent test it's impossible to save. A dead-lock overcome when you overpass the bucket size.
This is a simple test:
private void testPageConcurrentModificationException() {
ArrayList<RemoteDatabase> alTx = new ArrayList<>();
Set<String> concurrentPage = new HashSet<>();
boolean concurrentDetected = false;
int concurrentIntent = 10;
for (int i = 0; i < concurrentIntent; i++) {
RemoteDatabase tx = getDBTx();
tx.begin();
alTx.add(tx);
MutableVertex svt1 = tx.newVertex("SimpleVertexEx");
svt1.set("svex", "concurrent test"+i);
svt1.save();
System.out.println(""+i+": "+svt1.getIdentity());
}
// Throw the ConcurrentModificationException
for (RemoteDatabase tx : alTx) {
tx.commit();
}
}In this case, only the first save and the other get a CME eternally. In a real case, it hard to track what vertex/edge are involved to force a reload in each one. The database should track that.
I you have more than one vertex involved it get worst. You get dead-lock because there are multiple way to modify different vertex/edge so nobody save.
ArcadeDB use ConcurrentModificationException in a weird way. It throw that exception when a page is modified by somebody else, but who care about pages?
ConcurrentModificationException in all database represent that the record I need to commit was modified by somebody else, so I should decide what to do, overwrite the modified record o ask the user. That's the deal.
But with pages that is not true. The database throw that exception even when the data is ok and there no conflict and it seems there is no way to resolve what happens. A blind retry is not an option because I could overwrite something important, and ask the user in a heavy concurrent environment is not practical because we never end a simple save.
We have about 1254 user so every bucket change at every second. With the average creation of 873 case per morning day, every new page is modified by someone else, and we have more than a half of millon active cases that are updated at the same time.
CME should be launched only if the involved record are modified like was in OrientDB or any other database.
Actually in all our concurrent test it's impossible to save. A dead-lock overcome when you overpass the bucket size.
This is a simple test:
In this case, only the first save and the other get a CME eternally. In a real case, it hard to track what vertex/edge are involved to force a reload in each one. The database should track that.
I you have more than one vertex involved it get worst. You get dead-lock because there are multiple way to modify different vertex/edge so nobody save.