Hi Scott and Irene --) As always, thank you for taking the time to address the questions, all of which came up in the context of discussing EVN and its SDB (or Virtuoso or other) persistence bindings. The core question(s) revolve around the notion of how the definition of "transaction" -- which is reasonably well-defined in the RDBMS world in terms of criteria like ACID -- maps to graph operations. I think the summary of the discussion was something along the lines of: i) When EVN is bound to an ACID-compliant RDbMS (like SDB, SQLServer, etc.), there is transaction management at the "commit" level but that it is not guaranteed at the graph level per se (even though there is definitely audit trail management via TTF). There <<could>> be graph-level ACID-level transaction management at the graph level, but it is not guaranteed UNLESS ii) the TQ platform has specific SPW-based structures that seem to <<guarantee>> transaction management at the ACID level IFF the target persistence layer supports ACID-level transaction management.
A quick test of EVN during the discussion seemed to indicate that it was NOT fully ACID-compliant. Any comments on that? Are we correct in assuming that SWP <<does>> supply the ability to build pages that support graphs that are <<fully>> ACID-compliant if committing to SDB or other ACID-compliant persistence layers? Thanks in advance -- charlie On Thu, Feb 26, 2015 at 6:00 PM, Scott Henninger <shennin...@topquadrant.com > wrote: > Charlie; In terms of transaction management, one way to understand it is > that since a relational back-end is used to store all data, the > transactional guarantees from the relational system hold. I.e., all > changed are executed as fully or roll-back and retry; however the > relational system performs transactions. > > Contention (race conditions) are always a problem and the Teamwork > platform was designed to have a easy process for managing changes. > > If there are specific scenarios you would like to explore please let us > know. > > -- Scott > > On Thu, Feb 26, 2015 at 9:50 AM, Irene Polikoff <ir...@topquadrant.com> > wrote: > >> Charlie, >> >> I am not sure I fully understand the question, but I will try to answer >> in somewhat high level terms. If you need more details, maybe Scott could >> answer or we could pass your question on to the development team. >> >> As multiple users make edits, these edits are written into a database. >> More than one write transaction could hit the database at the same time. >> These transactions could be queued as we are using write-trough cache, but, >> depending on the scenario, single-writer strategy slows things down. We are >> using multiple write threads to SDB. Even with 'one at a time' >> transactional writes to TDB, there is no guarantee against locking >> contentions. >> >> Irene >> >> >> >> On Feb 26, 2015, at 10:22 AM, Charles Mead <iloveth...@gmail.com> wrote: >> >> Thanks Irene. A follow-up question is how the transaction management >> that lives in SDB (and that no one here doubts) is (or is not) manifest in >> EVN per se. In other words, what is the notion of "transaction management" >> at the graph level independent of its commitment to persistence through SDB? >> >> charlie >> >> On Thu, Feb 26, 2015 at 3:54 PM, Irene Polikoff <ir...@topquadrant.com> >> wrote: >> >>> We recommend SDB in the multi user read/write scenarios because it has >>> better support for transactions. If you have a load and read-only scenario, >>> TDB is a good choice. TopBraid includes a streaming data loader for TDB. >>> >>> Note, however, that there are some known issues with TDB on Windows. >>> They have to do with deleting TDBs. >>> >>> Regards, >>> >>> Irene >>> >>> >>> On Feb 26, 2015, at 9:47 AM, Charles Mead <iloveth...@gmail.com> wrote: >>> >>> Are there performance and size metrics available for why one would >>> choose to use one or the other of these approaches as an export/transfer >>> format? >>> >>> Thanks -- >>> >>> charlie >>> >>> -- >>> You received this message because you are subscribed to the Google Group >>> "TopBraid Suite Users", the topics of which include Enterprise Vocabulary >>> Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid >>> Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. >>> To post to this group, send email to topbraid-users@googlegroups.com >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "TopBraid Suite Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to topbraid-users+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google Group >>> "TopBraid Suite Users", the topics of which include Enterprise Vocabulary >>> Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid >>> Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. >>> To post to this group, send email to topbraid-users@googlegroups.com >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "TopBraid Suite Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to topbraid-users+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Group >> "TopBraid Suite Users", the topics of which include Enterprise Vocabulary >> Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid >> Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. >> To post to this group, send email to topbraid-users@googlegroups.com >> --- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to topbraid-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Group >> "TopBraid Suite Users", the topics of which include Enterprise Vocabulary >> Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid >> Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. >> To post to this group, send email to topbraid-users@googlegroups.com >> --- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Suite Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to topbraid-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Group > "TopBraid Suite Users", the topics of which include Enterprise Vocabulary > Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid > Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. > To post to this group, send email to topbraid-users@googlegroups.com > --- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to topbraid-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to topbraid-users@googlegroups.com --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
