Re: Writable lock nested in read-only lock

Svata Dedic wrote:
> 
> You risk that when your thread will attempt to promote its read lock to 
> a write one it will block (since there will be several other readers), 
> possibly holding other resources locked (those it locked from [1] 
> forward). If there's another thread, which also got the read lock and 
> waits on that resource or will wait to the previous one's output, you 
> get a deadlock.

Isn't this a problem no matter what, even if I start the outer 
transaction as a read-write transaction?

Let's say I have a thread A that has a read lock on the repository. Now, 
I want thread B to write to the repository, so I give it a write lock. 
If thread A waits for thread B to finish, there will be a deadlock. So, 
it seems to me not to matter if thread B does (read (write) read) or if 
it just does (write write write). And, two threads (A and B) cannot 
share a lock on the repository since there is a one-to-many 
correspondance between threads and locks.

On the other I could understand that MDR developers intended 
beginTrans(false)..endTrans() to mean that the repository should forbid 
all writes inside the transaction. But, I would think that there are 
more options that could be useful (READ_ONLY, READ_ONLY_PROMOTABLE, 
READ_WRITE, READ_WRITE_DEMOTABLE):

READ_ONLY: This transaction is read only, and nested transactions must 
be read-only.

READ_ONLY_PROMOTABLE: This transaction is read-only, nested transactions 
can be read-only, read-write, or read-write demotable.

READ_WRITE: This transaction is read-write, the transaction cannot be 
"demoted" to a read-only transaction.

READ_WRITE_DEMOTABLE: This transaction is read-write, the transaction 
can me "demoted" to a read-only transaction via some new API (e.g. 
MDRepository.modifyTransaction(READ_ONLY) or 
MDRepository.makeTransactionReadOnly()). Nested transactions can choose 
any of the four types of lock.

For my application, having READ_ONLY_PROMOTABLE would be perfect but 
READ_WRITE_DEMOTABLE (which should never cause any deadlock problems, 
right?) would be "good enough".

- Brian



> 
> -Svata
>