[castor-dev] Re: GSoC - A proposal for "Refactor lock engine"

Hi Ralf,

     I have tried to refactoring the Lock engine. Firstly, I extractor 
the TypeInfo class into a new class, but I have not separated the cache 
yet.

     I read the ObjectLock class, and I found that ObjectLock class 
implements some functions which are similar to the 
java.util.ReentrantReadWriteLock. I think the ObjectLock should extend 
ReentrantReadWriteLock, and then the ObjectLock will be easy to 
implementation, and the error will be less. And the api in 
java.util.ReentrantReadWriteLcok will provide great convenience.

     Is there anything I missed?

     Thank you very much in advance!


Best regards
Wensheng Dou

于 2011-3-28 8:36, Ralf Joachim 写道:
> Hi Wensheng,
>
> first of all I have to excuse for not having found enough time to
> explain some internals of Castor and give you background information of
> the task you like to apply for. I have only had a initial view at your
> proposal which seams good to me with regard to the information you have
> at the moment. I promis to spend some time this (monday) evening to give
> you some more explanations.
>
> At the moment I only have the time for some small hints.
>
> The copy of oswego libs have only been used for some special cache
> implementations that have been added when Castor had been compliant with
> Java 4. These have some bugs and therefor have not been used. While it
> would be good to convert them to Java 5 concurrent lib and remove oswego
> libs, this isn't the main focus of this project.
>
> Our problem is refactoring of Castor LockEngine. One thing is that
> current implementation of LockEngine uses an own locking implementation
> which should be replaced by Java 5 concurrency. But this isn't the main
> problem which can best be explained at load of an polymorph entity.
> Let's assume an entity B which extends another entity A. In such a
> scenario you can execute:
>
> db. load(A.class, 1);
>
> to load an entity of A or one of its subclasses having the identity 1.
> Question is, what happens inside Castor in that case.
>
> 1. TransactionContext is checked for the entity
> 2. An empty instance of A is constructed
> 3. This A instance is associated with TransactionContext
> 4. Cache is checked for the entity
> 5. A Lock is created for the entity
> 6. The entity is loaded from database
> 7. Now we recognize that the entity should be of class B instead of A
> 8. We have to release the lock
> 9. Remove the A instance from TransactionContext
> 10. Throw the A instance away and create a B instance
> 11. Associate B with TransactionContext
> 12. Create a lock on B
> 13. Put properties of B in cache
> 14. Set properties of B on the B instance
> 15. Return the B instance
>
> Main problems here are release and reaquiring lock as well as removal
> and reassociation of entity with TransactionContext as this causes
> Deadlocks.
>
> A second problem may be that we are locking entities instead of tables.
> Let's assume a entity C that has a list of D entities. From object
> perspective C holds a list of D's and therefore it should be enough to
> create a lock on C. But from database perspective the relation between C
> and D is maintained in D table which means we should also have locks for
> D entities or even better the relations between D's and C. Having said
> that we are not sure yet what to do here.
>
> I have to close for now but this should give you some ideas what to look
> for. Will follow up in the evening.
>
> Regards
> Ralf
>
> Am 26.03.2011 13:07, schrieb Wensheng Dou:
>> Hi Ralf,
>>
>> In last few days, I have read some documents and source code of Castor.
>> And I have written a proposal for “Refactor Lock engine” project (see
>> attachment).
>> Have I understood the purpose of this project? Do I need write an online
>> proposal, for example, a wiki page?
>>
>> Any suggestions are welcome.
>> Thanks in advance for your feedback.
>>
>> Best regards
>> Wensheng Dou
>>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email