db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: [OJB 1.1] Initial version check in
Date Wed, 11 Aug 2004 16:33:11 GMT
Hi Jakob,

Jakob Braeuchi wrote:
> hi armin,
> that's a big step for ojb, thanks !

Think the big steps will be the fixing of "small" issues ;-)

> i have one question about getting the Identity. in the prefetcher 
> classes lots of Identities are created using the new Identity(...). i 
> would like to use the IdentityFactory instead. what is the correct way 
> to access the factory ?

Identity oid = broker.serviceIdentity.buildIdentity(...);


> jakob
> Armin Waibel schrieb:
>> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org

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

View raw message