Re: How to circumvent transaction cache?


Boxuan Li
 

Hi Timon, what exactly is your data storage setup? For example, if you are using Cassandra (with replication) then there is no guarantee your current transaction can read latest value right after another transaction commits (even if your transaction does not cache anything).

JanusGraph is a layer built on top of your storage backend. Unfortunately, it cannot provide any guarantee that is not provided by the underlying storage backend at the first place. If you are concerned about ACID maybe you should use BerkeleyDB or FoundationDB.
 

On Mar 8, 2021, at 7:44 PM, timon.schneider@... wrote:

Hi all,

On Fri, Mar 5, 2021 at 05:32 PM, Ted Wilmes wrote:
Since you do not have ACID guarantees in most cases, I think you could still have a case where another transaction commits prior to your commit even though you saw isPublished = false when you check it. One possible way around this without ACID would be to process all mutations for a branch on one thread, effectively single threading access to it so that you could know that no other user was writing to the branch while you were reading.
I actually aim to keep the system ACID compliant. The only thing is (which I struggle to implement in JG) is that the edits only can be committed after a lock and read is done on the branch vertex' isPublished property. The problem is JG doesn't offer select for update functionality. I need to read the branch vertex to get the Id and lock it but while I'm getting it the isPublished property can be set to true by another user. Getting the vertex, locking it, and refreshing the data could be an option however it's not supported by JG.

Isn't this a shortcoming of JG that many users have issues with?

I think the single thread solution you suggest is not an option as our application is a meta data editor where multiple users should be able to edit elements of a branch simultaneously.

@Bo Xuan Li
I'm very much concerned with the consistency of the data. The check on the branch vertex is just a read operation necessary to guarantee that the branch is not published at the point of persisting the edits.

Join {janusgraph-users@lists.lfaidata.foundation to automatically receive all group messages.