BigdataSail#getUnisolatedConnection() uses a semaphore to impose the restriction that there can be at most one writer with the UNISOLATED connection at a given time. However, the semaphore is scoped by the BigdataSail instance and is thus unable to protect against applications which wrap the UNISOLATED view of a triple store instance more than once. Further, for ACID semantics in the standalone database, there should really only be a single UNISOLATED connection regardless of which triple store instance is address. E.g., if you have two different triple stores in the same database, the UNISOLATED connection should be restricted such that only one thread for one of those stores can hold that connection at a time. As it stands, it is possible for one thread to be granted that connection for each of those distinct triple store instances. However, doing so weakens the ACID semantics of an operation on the UNISOLATED connection since a commit invoked against one triple store could cause writes to be flushed through and incorporated into a commit point for another triple store.
This issue exists in the trunk and in the quads branch. It should be fixed in both.