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 01:05:25 GMT
Done! The files are in CVS.
Now I have to take a nap. I will report the 1.1 issues in a few hours. 
Don't get impatient! ;-)


Brian McCallister wrote:

> Excellent! I shall go play.
> -Brian
> On Aug 10, 2004, at 7:10 PM, 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.
>> 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