Read-only transactions are not explicitly closed by the client. This is fine for the in-memory store as they get garbage collected (GC'ed) when they go out of scope and no other clean is needed.

However this poses a problem for the distributed store. For all transactions, a ShardTransaction actor is created, which may be remote, by the front-end TransactionProxy which handles all read/put etc operations. For a write Tx, on commit or close, the ShardTransaction and associated actor are cleanup. But for a read-only Tx, there's nothing that cleans them up which results in a memory leak (verified via heap dump).

At the very least, we can utilize a timer to purge ShardTransactions (send PoisonPill message) that haven't been accessed for a period of time. To be safe we would need a rather long inactivity time out, say 10 minutes. We should do this for all transactions as a stopgap as, even for write Tx, the client-side node could go down before committing/closing or the client encounters an error that prevents it from committing/closing.

This could still lead to a build-up of stale ShardTransactions if there's a large burst of client transactions. We could try to be more proactive and clean up the back-end ShardTransaction when the front-end TransactionProxy is GC'ed, utilizing PhantomReferences and a reference queue. There's no guarantee an object will get GC'ed in any timely manner nor anyway to control that but client transaction instances should be relatively short-lived, i.e. created locally in a method, used, then go out of scope. In that case, they should generally remain in the young generation (eden) space and not get pushed to old generation. The GC cleans up objects in young generation much more frequently and efficiently than the old generation.