We're building out a rdf4j+rocksdb implementation. We started out with halyard (rdf4j+hbase) and swapped in rocksdb and removed some things that weren't rdf4j friendly trying to stick to native rdf4j a much as possible. Replication is pushed down to the rocksdb level so we can reuse replicated rocksdb for other things. We have requirements for oltp/olap use cases and need horizontal scaling and resiliency. I also want to push the envelope on federated sparql over large individual clusters; something I think semtech is designed to maximize.
Our initial approach to replication is by way of Kafka which solves our consensus as well as our distribution requirement. There are some limitations but, as noted, things are coming along nicely so far. We will look elsewhere if things don't pan out in production.
I absolutely believe the world needs an open source replicated 3store if we ever hope to accelerate the adoption of semtech in all directions.
That said, how do we make transactions less machine dependent? Perhaps an easy start is to make the ActiveTransactionRegistry pluggable?
Thx, matt
On Thursday, December 29, 2022 at 02:14:04 AM EST, Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:
Hi Matthew,
The code you linked to seems to be part of the REST interface. As I understand the code it’s used to be able to keep track of which UUID has been assigned to which transaction. The HTTP client can then add the UUID as a param so that the server is able to find the underlying RepositoryConnection object where it started the transaction.
Could you give us some more details about your approach to replication and which use cases you need to solve?
Håvard
On 28 Dec 2022, at 23:44, Matthew Nguyen via rdf4j-dev <rdf4j-dev@xxxxxxxxxxx> wrote:
Hey folks, we're working on replication logic for an implementation of rdf4j at work (eg multinode 3store). Making some decent progress (hoping to contribute back once things look good for us in prod) but encountered an issue while trying to implement transactions. So far, it looks like rdf4j transaction keeps local in-memory state via the ActiveTransactionRegistry (https://github.com/eclipse/rdf4j/blob/56d550fdd516657fbdcb0c2a8dc64b06c47c443d/tools/server-spring/src/main/java/org/eclipse/rdf4j/http/server/repository/transaction/TransactionStartController.java#L154). Would you guys be open to moving away from local in-memory state and maybe serializing it to the local store instead (perhaps in a different context of the repo) to make replication easier?
matt
