An issue has been observed with the BigdataSail and the NanoSparqlServer where the latter obtains a read-only transaction from the last commit time on the database and the former treats that transaction identifier as a commit time and attempts to obtain a read-only transaction for that timestamp. This was causing an exception to be thrown indicating that the transaction identifier (when interpreted as a timestamp) was GT the lastCommitTime on the database.
The goodness of obtaining a read-only transaction from a read-only transaction are questionable. This is probably not incorrect, but it could lead to nested acquisition of read-only transactions from read-only transactions, which does not add any value and will impose unnecessary latency on operations which are already protected by a read-lock.
Read-write transaction identifers are readily identified by their sign bit, which is negative. However, currently, there is no way to distinguish timestamps from read-only transaction identifiers. This means that the code path must be recognized in advanced and appropriately distinguished methods called, e.g., getReadOnlyConnectionWithTimestamp(long) versus, getConnectionWithTx(long).
Rather than develop such complicated naming conventions, it might be worth while to propagate a flyweight object to serve as a transaction identifier. This was differentiate read history operations without read-locks from those with read-locks based on the method signature. However, this again can cause us to have twice as method methods on the API.