Is the recommended migration path to do the following instead of the bulk update:
Start a transaction Insert each triple Commit transaction With the assumption that the underlying transaction implementation will batch the update to the storage layer? Claude On Wed, Sep 4, 2013 at 10:14 AM, Andy Seaborne <[email protected]> wrote: > It has to be the applications responsibility to add transaction boundaries. > > * JDBC connection re often controlled by the environment such as pooling. > > * The application may already be in a transaction. > > * Transactions are logical grouping of actions. > Model operations are not application logical boundaries. > The application will want a group of model operations in > one transaction. > > * Nested transactions are rarely supported. > > Aside from everything else, TopQuadrant should be using transactions. > Auto-commit could easily explain 40s. We can't tell - it's closed source. > > TopQuadrant can call the SDB controls. Jnea is open source - see the code > starting at UpdateHandlerSDB. > > -- from GraphSDB -- > > store.getLoader().**startBulkUpdate() ; > .... do stuff ... > store.getLoader().**startBulkUpdate() ; > > -- > > >> As this is quite a > >> crucial issue for our upgrade right now, > > TopQuadrant have already released recently. > https://groups.google.com/d/**msg/topbraid-users/** > El9BbRV6wk4/ac-602N2emoJ<https://groups.google.com/d/msg/topbraid-users/El9BbRV6wk4/ac-602N2emoJ> > > Re: SDB > > The position of SDB has been discussed: > http://mail-archives.apache.**org/mod_mbox/jena-dev/201305.** > mbox/%3C519BA513.1030403%**40apache.org%3E<http://mail-archives.apache.org/mod_mbox/jena-dev/201305.mbox/%3C519BA513.1030403%40apache.org%3E> > > > >> we could gain time for a proper redesign > I'll detail the history of BulkUpdateHandler in a separate message. > > This message is relevant: > http://mail-archives.apache.**org/mod_mbox/jena-dev/201305.** > mbox/%3C51A5678A.5070607@**knublauch.com%3E<http://mail-archives.apache.org/mod_mbox/jena-dev/201305.mbox/%[email protected]%3E> > > where Holger writes: > [[ Subject: [DISCUSS] SDB future > Having to rely on commercial alternatives would affect > the overall price tag of our solutions, and having an open source > solution that seamlessly works with Jena is a great asset. > > I have brought up the topic of this thread in our management to see > whether we can allocate any resources to its future, but I cannot report > any decision at this stage. > ]] > > My suggestion is a add a Graph that does batching. > > In fact, my advocacy is that all additonal functionality (events, > batching, read-only, security, ...) are done by graph-wrapping AKA > implementation inheritance. > > Transaction should be consolidated on the dataset interface. > > -- > > Currently, as SDB patches come in, I personally try to find time to apply > them. I don't have an SDB test system and certainly do not have setups of > each of the databases with SDB adapters. > > Such time is my time - my employer doesn't use SDB. > > Andy > > > > On 04/09/13 01:32, Holger Knublauch wrote: > >> On 9/4/2013 3:15, Claude Warren wrote: >> >>> As I recall the discuss around this topic dealt with the idea that you >>> could add each triple inside a transaction and when the transaction >>> committed transaction code would do the bulk update if supported. >>> >> >> If this were the case, then the code in the GraphUtil helper functions >> should probably wrap the individual performUpdate calls with a >> transaction, but they don't. >> >> However >>> I may be way off base here. I have no objection to retaining the BUH. >>> >> >> I would greatly appreciate seeing this resolved before the final >> release. As suggested earlier, we could gain time for a proper redesign >> by avoiding the calls to the GraphUtil replacement functions, or >> changing those functions so that they call graph.getBulkUpdateHandler() >> for the time being, and possibly undeprecate BUH for now. >> >> Thanks, >> Holger >> >> >>> Claude >>> >>> >>> On Tue, Sep 3, 2013 at 12:17 AM, Holger Knublauch >>> <[email protected]>wrote: >>> >>> Hi group, >>>> >>>> I did not see any response to my question below, which is usual for this >>>> list where responses are usually fast and competent. As this is quite a >>>> crucial issue for our upgrade right now, I would like to ask again, and >>>> rephrase my question. I understand SDB is rather unsupported, but the >>>> issue >>>> is really a question on the core API. >>>> >>>> Deprecating the BulkUpdateHandler will not only affect SDB but any other >>>> database such as Oracle RDF (the Jena adapter of which implements its >>>> own >>>> BUH right now). Granted, the class is not gone yet, but some existing >>>> API >>>> calls (Model.add) already bypass the BulkUpdateHandler, and I believe >>>> this >>>> was premature (revision 1419595). My suggestion is to continue to >>>> delegate >>>> Model.add through the BulkUpdateHandler for the upcoming release >>>> until the >>>> interface has been truly removed/replaced with something else. BUH >>>> does not >>>> represent much implementation overhead for Graph implementers, >>>> because they >>>> can simply use the default implementation. The current implementation is >>>> too inefficient for our product. >>>> >>>> If there is a cleaner mechanism to get the same performance, then I'd be >>>> happy to hear about it. >>>> >>>> Thanks >>>> Holger >>>> >>>> >>>> >>>> On 8/29/2013 9:39, Holger Knublauch wrote: >>>> >>>> SDB currently implements its own BulkUpdateHandler, and I just made >>>>> some >>>>> tests that indicate that it is significantly faster than using >>>>> GraphUtil.add (2 seconds versus 40 seconds for 10k triples). Now that >>>>> BulkUpdateHandler has been deprecated, and Model.add is already using >>>>> GraphUtil.add, what call sequence are we supposed to use to retain >>>>> the good >>>>> performance of the BulkUpdateHandler? Could a method >>>>> Graph.add(Iterable<Triple>) be added to allow graphs to optimize the >>>>> behavior for specific Graph types? >>>>> >>>>> Thanks >>>>> Holger >>>>> >>>>> >>>>> >>> >> > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
