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
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
>> 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/%[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
