Updating literal objects best practices

Hi,

In my usecase i am maintaining a data property predicate like this :
< task1 > < status > " pending "
Now this task will go through multiple states pending, assigned, onhold, inprogress, complete etc
There will be only 1 status at any given time for a task.

Right now on each update i am doing :
deleting < task1 > < status > ?o
and then insert < task1 > < status > " assigned "

I will have few thousand such tasks for update in a request as user do selections on application UI.
My approach to support is :
Collecting all delete statement running as batch using SPARQL DELETE where { { } {} {} }
and same approach for batch inserts. SPARQL INSERT INTO { . . . }
To avoid max query size doing in batches of 1000 or N triples in { }

Two questions i have :
a) is this right way to update status property ? What could be better performant alternative ?
Any possibility in owl/rdf definition i can define 1 cardinality for status predicate then db layer
ensure maintaining 1 value only then my application layer will get simple.

  b) transaction part...
      if my delete batch succeed but  insert batch fail then will have inconsistent DB..
      If one of insert batch fail after few batches then will have inconsistent DB...
      How can i ensure consistency for these thousand tasks update?

I am using https://github.com/knakk/sparql golang client
for executing these sparql queries on virtuoso.

Please guide on possible solutions and best practices for this usecase.

Thanks,
N Yadav

Fundamentally, this is an issue of Transaction Semantics Fidelity i.e., how much control do you have over transactions. By default, all SPARUL statements a committed following execution, or rolled back. A Virtuoso SPARQL Endpoint provides basic auto commit transaction functionality. Thus using https://github.com/knakk/sparql golang client indicated which queries against a SPARQL endpoint you will not have transaction control.

You need a semantically rich transaction layer when you want more specific conditional behavior provided by isolation levels, transaction blocks, and rollbacks or commits. Which is supported and available in Virtuoso via one of the SQL Data Access interfaces ie ODBC/JDBC/ADO.Net/Jena/Sesame etc to get transaction support.

See Also:

Virtuoso RDF and Transactions
How Virtuoso extends SQL with SPARQL and vice versa
Virtuoso JDBC Transaction Simulation Program

@hwilliams thanks much for explaining transaction part, i am clear on possible direction.

Ignoring transaction issue,
Please also guide on best practice to maintain < status > dataproperty of thousands of tasks.

Is the current approach mentioned by me in thread is the optimal way ?
( i.e single query multiple delete triples < status > then single query multiple insert triples < status > )

Thanks,
N Yadav

Note sure what you mean by SPARQL DELETE where { { } {} {} }, but would have thought using SPARQL 1.1 Update INSERT/DELETE operations to perform group deletes and insert on multiple triples at the same time, such that the delete and insert operations are performed simultaneously and either all fail or succeed as a single query executed against the database, which Virtuoso supports