Transaction issue

[Sysvision]

We have encountered some strange transaction issues inside or application when using remote connections. For some reason I can only reproduce this with the console application.

OrientDB version I am using: v.1.6.0-SNAPSHOT 20131010-1330

orientdb> CONNECT remote:localhost/test admin admin
Connecting to database [remote:localhost/test] with user 'admin'...
OK
orientdb> select from v

0 item(s) found. Query executed in 0.002 sec(s).
orientdb> begin

Transaction 1 is running
orientdb> create vertex v set col2 = 'test', col2 = 10

Created vertex 'V#9:0{col2:10} v0' in 0.011000 sec(s).

orientdb> rollback

Transaction 1 has been rollbacked in 1ms
orientdb> select from v
----+----+----
#   |@RID|col2
----+----+----
0   |#9:0|10
----+----+----

1 item(s) found. Query executed in 0.002 sec(s).

When using local connections the results are as expected:

orientdb> CONNECT local:/opt/orientdb/databases/test admin admin
Connecting to database [local:/opt/orientdb/databases/test] with user 'admin'...
OK
orientdb> select from v

0 item(s) found. Query executed in 0.001 sec(s).
orientdb> begin

Transaction 1 is running
orientdb> create vertex v set col2 = 'test', col2 = 10

Created vertex 'V#9:-2{col2:10} v0' in 0.017000 sec(s).

orientdb> rollback

Transaction 1 has been rollbacked in 2ms
orientdb> select from v

0 item(s) found. Query executed in 0.001 sec(s).

After that I wrote a small Java app to reproduce the problem, but for some strange reason everything works fine in this small scale app.

OrientBaseGraph graph = new OrientGraph(databaseUrl, username, password);
graph.addVertex("class:V", "col1", "val1", "col2", 10);

System.out.println("Before rollback: ");
dumpRecords(graph);
graph.rollback();
System.out.println("After rollback: ");

dumpRecords(graph);
graph.shutdown();

[Sysvision]

I just realized that I never called save() on the newly created vertex in the test app. When I looked at the OCommandExecutorSQLCreateVertex class the execute() calls save() on the vertex. So I thought it might have something to do with the save() and removed all calls to save() from our large scale application. And now everything seems to work. When I call commit() the vertices/edges are inserted in the database and when I call rollback() nothing is inserted, just like one would expect. So for me it seems calling save() is unnecessary anyway. Is this correct? Can you tell me when I have to call save()?

After that I tried again with the test app and added a call to save() right after addVertex(), but the issue still won't occur in small scale. :(

[lvca]

What API are you using? The old native Graph API? Use TinkerPop ;-)

[Sysvision]

I use tinkerpop API as you can see in the sample java code. Maybe my confusion comes from the fact that the Blueprint OrientElement has a method called save(). I always thougth I had to call OrientElement.save() to actually save the element.

But on a transactional graph the save() somehow already commits the transaction, so calling rollback() won't work. When I remove the save() call rollback() works fine. And calling commit() actually stores the element, even without ever calling element.save(). So I better not call save() at all?

And again try running this little sql script with your console application (which uses the new tinkerpop API and also calls save() for create vertex), once with remote and once with local connection, and you'll see different results. For local connection create vertex returns a temporary vertex (rid is #9:-2) and the select returns 0 results whereas for remote connections create vertex already stores the vertex (rid is #9:0) and select returns 1 result (#9:0) even after rollback.

begin
create vertex v set col1 = 'test', col2 = 10
rollback
select from v

[lvca]

Hi look at Isolation when use "remote": https://github.com/orientechnologies/orientdb/wiki/Transactions#isolation

About save() it's non BP but internal. It's useful when you act at document level to speed up setting of properties.

[Sysvision]

Ok, but Isolation doesnt explain why the data is not rolled back, does it? I didn't mean to execute the sql at the same time with 2 transactions doing different stuff. Just execute the sql for "remote", nothing else. From my experience with other DBMS I thought that begin; insert into table...; rollback; will leave an empty table (assuming it was empty before) which apperantly isn't the case when using OrientDB console with "remote"

[lvca]

the transaction is executed on client side, while all the SQL command at the server side. That's why. By using the console this has poor sense, but with Java apps more. We've an open issue to let to OrientDB to start the tx on the server side (like RDBMS).