db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: [OJB 1.1] Initial version check in
Date Wed, 11 Aug 2004 00:21:53 GMT
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


Mime
View raw message