Your very last statement
"Fuseki is set of servlets. It is wrapped in a Jetty instance to give
the standalone server.
You could choose to use the servlets inside a large web application
thereby sharing the TDB engine."
is what I was hoping you would say.
That's great!
-----Original Message-----
From: Andy Seaborne [mailto:[email protected]]
Sent: Friday, August 16, 2013 7:56 AM
To: [email protected]
Subject: Re: TDB: Fuseki, one's own server, hybrid?
On 15/08/13 16:02, David Jordan wrote:
> A TDB dataset only allows a single JVM to access/manage it at a time.
> It is my understanding that Fuseki is primarily simply a SPARQL
> endpoint server to issue queries to for one or more TDB datasets.
Yes - TDB and any other datasets.
Fuseki is the protocol engine.
> One
> can also write their own TDB application, creating their own TDB
> access server, using the TDB libraries. While it is possible to
> support SPARQL queries through the TDB libraries, it “may” be the case
> that the multi-client serviceability mechanisms that are built into
> Fuseki are not directly available in the TDB libraries if one is
> wanting to also add their own non-SPARQL access code.
The key is that there must be only one database engine per set of files on
disk. The same is true for any SQL database as well. ODBC or JDBC are
protocols for accessing a shared, single database engine.
> I believe it is
> the case that TDB would not allow both a Fuseki server as well as
> one’s own server accessing the same TDB instance.
If there are in the same JVM, that can be done.
> Is there any means
> to enable a hybrid approach, where you can have a server that includes
> all the capabilities provided by Fuseki, but also allow for extending
> that server to support access to code that one would write directly
> against the TDB and Jena libraries?
Fuseki is set of servlets. It is wrapped in a Jetty instance to give the
standalone server.
You could choose to use the servlets inside a large web application thereby
sharing the TDB engine.
Andy
