db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject [OJB 1.1] Initial version check in
Date Tue, 10 Aug 2004 23:10:32 GMT
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.

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.

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.

All issues and missed ports from 1.0 to 1.1 will following in a separate 
mail, I don't want to do evil mood ;-)

regards,
Armin



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


Mime
View raw message