RE: [OJB-developers] features

[Bischof, R. <rai...@ed...>]

All,

I just had a closer look at the locking stuff as it is implemented right
now.
The only class that makes locks persistent is the AbstractLockStrategy.
Unfortunately all LockStrategies inherit from that which limits re-use of
the useful code in and around the LockStrategies.

What about the following approach for the new in-memory locking:
* We extract those parts of the AbstractLockStrategy that store / retrieve
the persistent locks. These parts go into a PersistentLockServiceImpl which
implements a LockService interface. We create a similar class
InMemoryLockServiceImpl that does the same without accessing the DB. (does
anybody have a better name for the last class??) 

* We change the AbstractLockStrategy not to perform DB access itself but to
use an implementation of the LockService interface for these activities.
 
* The LockStrategyFactory configures the LockStrategies created to use the
appropriate LockService implementation (persistent/in-memory).

That way we can re-use the complete LockMgrDefaultImpl, LockEntry,
LockStrategyFactory, the different Lockstrategies and their configuration.
Most of the logic in AbstractLockStrategy can be re-used in the
PersistentLockServiceImpl. We should not have any API changes at all. It
seems to be a clean approach.

Have I missed something? Looks just too easy. I'm sure I missed something...
Any comments?


Thomas, 
is this similar to your intended approach or do you have another idea?
I guess it's not that much work for you to provide me a method "String
getLockServiceClass()" in PersistenceBrokerFactoryConfiguration, right? That
way I only have one area to work on and don't have to find my way through
the configuration stuff as well.
Or do we need to have different locking approaches for different classes?
Than I have no idea how to get that information per class as I have not
really looked into the XML configuration classes... ;-)

Regarding the timing: I hope to find some time for this end of next week so
it might have a chance to go into the next release if it passes the unit
tests. 

Thx
rb


Rainer Bischof
EDS - Electronic Data Systems
European Automotive Solution Center - Distributed Solutions
Email: rai...@ed... <mailto:rai...@ed...> 


-----Original Message-----
From: Thomas Mahler [mailto:tho...@ho...]
Sent: Montag, 19. November 2001 12:56
To: Bischof, Rainer
Cc: obj...@li...
Subject: Re: [OJB-developers] features


Hi Rainer,

> 
> I don't know if you have been working on this: What about the single VM
> LockManager?

Yes I just started working on it yesterday. I used the well established
Interface/ConfigurableFactory Pattern to make it pluggable.

> If you have not started I will try my best to implement it. I need it
> sometime in December as the LockMgr is the main performance bottleneck for
> us...
> If you have already started but have other priorities you could probably
> provide me your stuff and I will continue...
> 

Oh, that will speed up things a lot! I will clean up my code a bit and
then post you a current snapshot! 

> Btw: I have rarely seen a project with a project lead as repsonsive as
you!
> Keep up the good work.
> 

Thank you, these compliments speed up things even more, as they result
in better motivation of the "OJB bottleneck" ;-)

-- Thomas