db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: [OJB 1.1] Initial version check in
Date Wed, 11 Aug 2004 16:06:01 GMT
hi armin,

that's a big step for ojb, thanks !

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 ?


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

View raw message