db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Dudziak <to...@first.fhg.de>
Subject Re: [OJB 1.1] Initial version check in
Date Wed, 11 Aug 2004 09:36:24 GMT
Armin Waibel wrote:

> Hi all,
> with two weeks delay (sorry Tom) I will start today with the initial
> check in of the OJB 1.1 stuff (Before check in I will create a tag for
> current trunk - BEFORE_1_1). This will make the trunk unstable for 
> production use. I modified, add and remove a bunch classes, but most 
> test cases of the test-suite should pass after check in further on.


> I tried to get rid of all the singletons in kernel classes (90% of work
> is done) and make OJB instance based. Now OJB depends on a "start class"
> OJB.java. Additionally I introduced the new PersistenceConfiguration
> concept, a new top-level metadata configuration, Tom has posted this
> idea some weeks ago
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=ojb-dev@db.apache.org&msgId=1760525

> A PersistenceConfiguration (PC) include one persistent object model
> (DescriptorRepository), one connection (JdbcConnectionDescriptor) and a
> CacheManager instance manage all used caches (per connection cache, per
> class cache) and some time in future the handling of sequence manager
> instances.
> Currently I use a workaround to make it work with 'old' repository.dtd
> and metadata classes. This will be changed with the new upcoming
> metadata handling/parsing.
> Each PC has its own PBF implementation instance. Each PBF implementation
> instance now manage one pool of PB (in 1.0 PBF manage a KeyedObjectPool,
> with PBKey as key). To lookup a PB instance we will use an PCKey (a key
> represents one PC) instead of a PBKey (a key represents one JCD 
> JdbcConnectionDescriptor).
> Currently I use the PBKey in a way like the PCKey (PCKey.java is not yet
> introduced). Tangling! ;-)
> I do my best to make 1.1 backward compatible. After tweaking OJB
> test-suite most PB test cases pass. To use the PB-api in the same way as
> in 1.0 I modified the static wrapper class PersistenceBrokerFactory and
> add static set/getOjb() method. Before the first use the OJB instance
> have to be set.
> In the test suite base class this looks like:
> public class OJBTestCase extends TestCase
> {
>     ...
>     public static OJB ojb;
>     static
>     {
>         ojb = new OJB();
>         // TODO: fix this!! This makes old tests compatible with 1.1
> version
>         PersistenceBrokerFactory.setOjb(ojb);
>     }
> ...
> After setting a OJB instance, PBF can be used as in 1.0
> Most factory classes now available via OJB.getFactories(), which returns
> a Factories.java class instance. This class provide most used factories
> (IdentityFactory, ConnectionManagerFactory, ConnectionFactoryFactory,
> ...). Seems to me the easiest way to replace the singletons - Comments
> are welcome.

How many factories are there, anyway ? Could we merge some into other 
objects, e.g. PBF into OJB.java or similar ?

> The ConnectionManager/ConnectionFactory/ConnectionFactoryFactory 
> classes are reworked too.
> Each PB instance was associated with an ConnectionManager (done in PB 
> constructor). The ConnectionManager use the JCD of the associated PC 
> (remember each PB was bind to one PC) to lookup a ConnectionFactory 
> from the ConnectionFactoryFactory. So each JCD (defined in repository) 
> represents one ConnectionFactory and different PC can share the same JCD
> respectively the same ConnectionFactory. In the connection-pool 
> element it is now possible to declare the ConnectionFactory 
> implementation, thus it will be possible to use a separate 
> ConnectionFactory implementation class for each JCD.

So we should have something like a connectionfactory-class attribute at 
the JCD ?

> Another change was made in handling of the StatementsForClassIF 
> instances. In 1.0 each ClassDescriptor managed one instance of 
> StatementsForClassIF, it was bound to the model. But this class use an 
> SqlGenerator instance which based on the used Platform. Thus using a 
> class-descriptor with different databases will cause problems. Now 
> each class-descriptor manage a Map of StatementsForClassIF instances 
> based on the used JCD (of the PB argument).
> The caching was reworked too. Main class is LocalCache.java. Each PB 
> instance has an LocalCache instance. The local cache of the PB 
> instance buffer object instances while running tx and push all 
> buffered objects to the second level cache on commit. The second level 
> was represented by class CacheManager. The CacheManager was bind to 
> the used PC, thus the second level cache is shared across different 
> threads (and in some cases across different PC). The CacheManager is 
> responsible to handle the different sorts of caches (per class, per 
> connection). The real caches are instances of ObjectCache (modified 
> version of 1.0), but all ObjectCache instances are wrapped by a 
> CacheStrategy instance. The CacheStrategy can be used to filter, 
> modify or copy cached objects.

I was wondering how the OJB configuration (OJB.properties) should be 
handled then. My initial idea is like this:

The complete configuration is done via the OJB object and sub-objects. 
For backwards-compatible operation, a static method is probably needed 
(e.g. PersistenceBrokerFactory.defaultPersistenceBroker() ) which 
creates a static OJB instance, and also configures this instance from 
A helper configurator bean (e.g. OJBConfigurator) can be used to 
configure an OJB object by reading a properties file and setting the 
properties accordingly. It translates (for compatibility) the current 
unqualified property names to fully qualified ones, and uses these 
qualified properties to intialize the factories, create instances as 
needed, and set properties on them.

Does that sound reasonable ?


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message