The Islandora community developing the new CLAW software have needs for transactions around

  1. Atomic - Ability to batch operations together that all execute or all fail together
    1. Add a new binary resource to Fedora
    2. Update the new resource with RDF from user.
    3. Update the new RDF resource with a system generated UUID.
    4. Commit all changes.
  2. Consistency - We have no requirement from the Fedora API for consistency.
  3. Isolation - ??? (This is still in discussion and will update...soon as of 2016-01-27)
  4. Durable - My understanding of durable is that we want our changes to be saved in the case of a system crash. Unless I am misunderstanding this, then this is what Fedora does no?

-- Tagging Unknown User (daniel-dgi), Nick Ruest, Diego Pino Navarro, Nigel Banks for input.

 

6 Comments

  1. A. Soroka

    Y'all are using "consistent" in a very different sense than the normal use of the word in the context of ACID transactions. You are talking about the distribution of networks of persistence, which, while very important to the Fedora community, is explicitly not under discussion as part of the API specification.

    1. Jared Whiklo

      That would be my misunderstanding of the concept. Having done some Googling and reading, I am now of the opinion that we don't need "Consistent" as defined as part of an ACID transaction. But I will also let the others in development have their say, in case I have missed something.

  2. A. Soroka

    Your understanding of "durability" is on target. Wikipedia is pretty accurate here.

  3. Diego Pino Navarro

    Consistency refers to not corrupting our repo storage in case something goes wrong during TX, basically keeping a correctness state. So eventually consistent is something we would need to discuss? E.g, eventually consistent could be a partial committed transaction (because of a bug, whatever) that does trigger an activeMQ message and by this and Sparql update into the triple store. So we end with triples but no real resources in fedora, but still with a working repo? In this case is activeMQ considered as part of the transaction life cycle -> result? I would love to think of consistency in terms of, e.g, keeping the LDP functionality in place in case of errors. Like if we are adding an indirect container with  ldp:hasMemberRelation and that one fails for whatever reason, we don't end with and auto-adding-predicate parent resource on top of it. Not sure if i explain myself.


    Found this: maybe clarifies consistency

    Consistency. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started

  4. David Wilcox

    Jared Whiklo is this use case still relevant?

  5. Jared Whiklo

    No, Islandora has moved to abiding by the Fedora specification. So while transactions are a nice feature we have moved to other ways to fulfill these needs.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.