Transaction implementation in client with a pool of connections


I’m implementing a client for dgraph and by implementing transaction, I got questions.

Documentation says: Each client will need to keep a linearized reads (lin_read) map.

What if I have a pool of connections to dgraph database? How it should be handled, every connection should have own lin_read map or lin_read should be shared for all connections in a pool?

It can happen, that some client from the same node will get connection 1(from a pool) execute transaction with connection 1 and execute next transaction with connection 2, because in between of this transactions some other process will get connection 1 from a pool. The transaction will work, but it could happen, if every connection will have own lin_read, that the same client will modify something in transaction 1(via connection 1) and willn’t see own modification in second transaction (via connection 2)?

Do I understand it right?

I see this solutions:

  • track lin_read not only in a connection process, but in a working processes (so that the same process will never have smaller lin_read by getting another connection)
  • having one lin_read, which will be single bottleneck for the client.

Thank you in advance for any clarification.

The short answer is lin_read is no longer used since v1.0.9 and do not need to be implemented in clients. If you check the responses from Dgraph you won’t see any lin_read values returned.

1 Like

Thank you for answer.

Another question about transactions than, but I still need to track the start_ts, should the consequent transaction have start_ts higher, than previous transaction or is it enough to get start_ts from a first server response inside transaction?

The initial start_ts can be 0. Then for the next request you can update the start_ts with the one from the server response.

You can check out the implementation of the official Go client as a reference implementation. It’s also the reference implementation we use to implement the other official clients.

@liveforeverx Hi!

I’ve been loving Dlex so far, but can’t seem to get it working with Slash Graphql (hosted dgraph) - I’d buy you a beer if you have a sec to give me a nudge in the right direction :slight_smile: