| 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
_______________________________________________rdf4j-dev mailing listrdf4j-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/rdf4j-dev
|
