Wensheng Dou
2011-04-02 06:55:00 UTC
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
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
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
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
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
---------------------------------------------------------------------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
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
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
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