Reputation: 73
I have been reading about GraphDB recently and in the documentation it mentions that GraphDB is ACID comliant. But there is very limited documentation about how far it goes. I am developing a REST API and was wondering how do I solve the problem of lost updates with GraphDB. For each resource, our API is returning an Etag. When clients want to update the resource they need to supply etag. Then in a transaction I want to check if the etag provided by client matches with etag in database only then do the update. In high concurrency usage it is possible that more then one clients can present same etag and if etag check and update is not in same transaction then one transaction can overwrite changes from other transaction. My question is, is it possible in GraphDB to acquire some sort of read lock when check is performed so that no other transaction can update the value?
Upvotes: 0
Views: 553
Reputation: 2601
You can add the etag check in the INSERT WHERE update. If the etag does not match, the insert will insert no triples.
Upvotes: 0
Reputation: 1142
GraphDB is fully compliant ACID database (http://graphdb.ontotext.com/documentation/free/storage.html#transaction-control). You can safely have multiple users and no single interaction with the database may have side-effects on the other interactions. There are no issues with concurrent reads or writes. In addition in GraphDB EE when a user execute a single update containing multiple "insert where' and/or 'delete where' expressions separated by ';' in such case each of the subsequent expressions can 'see' the changes when evaluated from the previous ones in the same update but the scope is the same composite update. The engine do not support concurrent writes because we could not guarantee the consistency of the data, in particular, when inference is involved.
Upvotes: 1