Le 6/13/12 3:18 PM, Göktürk Gezer a écrit :
Hi Guys,
Hi Göktürk,
I have a little question with probably quick answers:
* Lets assume LdapServer is issuing some operation through
DirService.OperationManager. If i change the code in OperationManager to
obtain a Lock of target Partition which is exclusively owned by other
thread which is destroying the Partition. What happens then?
Whaouh... A lot of things. When we do a search, we get back a cursor
that will get data from the partition, and it can take a lot of time.
But when the cursor has been provided, we are already out of the
OperationManager. Locking the partition will just freeze the search, and
I'm not sure it can restart finely. Frankly, for searches, I don't see a
fine way to resume if the partition has been swapped out and replaced,
except stopping the operation, and informing the user with the
appropriate message...
For the other operations (modifications), I do think the best is to
stack the incoming operations when you have acquired the lock so that
you can restart them when you are done with the partition, but you at
least should wait for the ongoing modifications to be completed.
-> Does ConcurrentReadWriteLock has some method to cause exception to be
thrown in Readers. I mean can i issue some kind of Abort on all waiting
readers when i'm actually destroying its attached object. (Yeah i'm Java
noob ATM :) )
You can get a list of the Threads actually waiting on the lock :
|*getQueuedThreads
<http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html#getQueuedThreads%28%29>*()|
" Returns a collection containing threads that may be waiting to acquire
either the read or write lock."
-> If this is not possible, does LdapServer's current threading model
ends the issued operation due to timeout or it just sits there(which would
be bad)?
We certainly have to abort the operation correctly, by sending a
LdapMessage with a specific code to inform the users that something went
wrong.
Regards,
Gokturk
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
