Menu
▾
▴
[OpenEMed-commits] OpenEMed/dist/servers/coas OJB.properties, 1.11, 1.12
|
From: David F. <dwf...@us...> - 2006-11-03 18:52:14
|
Update of /cvsroot/openmed/OpenEMed/dist/servers/coas In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv30361/dist/servers/coas Modified Files: OJB.properties Log Message: Updated OJB.properties for ojb1.0.4 Index: OJB.properties =================================================================== RCS file: /cvsroot/openmed/OpenEMed/dist/servers/coas/OJB.properties,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -d -r1.11 -r1.12 *** OJB.properties 22 Apr 2005 05:29:04 -0000 1.11 --- OJB.properties 3 Nov 2006 18:52:08 -0000 1.12 *************** *** 27,31 **** # repository. The file is looked up from the classpath. # - #repositoryFile=repository.xml repositoryFile=ojb//config//hsqldb_repository.xml # --- 27,30 ---- *************** *** 65,68 **** --- 64,76 ---- #PersistenceBrokerClass=org.apache.ojb.broker.prevayler.PBPrevaylerImpl # + # + # This setting can be helpful during development if the PersistenceBroker transaction + # demarcation was used (this is true in most cases). If set 'true' on PB#store(...) + # and PB#delete(...) methods calls OJB check for active PB-tx and if no active tx is + # found a error is logged. This can help to avoid store/delete calls without a running + # PB-tx while development. Default setting is 'false'. (Note: When using OJB in a managed + # environment *without* OJB-caching, it's valid to use store/delete calls without a running PB-tx) + TxCheck=false + # #---------------------------------------------------------------------------------------- # PersistenceBroker pool *************** *** 134,139 **** ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl - #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl # # --- 142,149 ---- ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryNotPooledImpl #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl + # Only needed when using OJB 1.0.3 or earlier in managed environments. Since version + # 1.0.4 OJB detects datasources from managed environments automatically. + #ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl # # *************** *** 153,162 **** # #---------------------------------------------------------------------------------------- ! # IndirectionHandler #---------------------------------------------------------------------------------------- # The IndirectionHandlerClass entry defines the class to be used by OJB's proxies to # handle method invocations # ! IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl # #---------------------------------------------------------------------------------------- --- 163,189 ---- # #---------------------------------------------------------------------------------------- ! # ProxyFactory and IndirectionHandler #---------------------------------------------------------------------------------------- + # The ProxyFactoryClass entry defines which ProxyFactory implementation is to be used. + # By default, a 1.0 compatiable, JDK-based version is used. However, a the CGLIB based entry + # is available. + # + # - ProxyFactoryCGLIBImpl: Refernece proxies are generated using bytecode manipulation + # from the CGLIB library. Any class can become a dynamic proxy, and not just ones + # that implement an interface. + # - ProxyFactoryJDKImpl: OJB 1.0 compatiable Proxy implementation. Proxies in this method + # can only be generated from classes that implement an interface, and the generated + # Proxy will implement all methods of that interface. + # + # NOTE: The appropriate cooresponding IndirectionHandler must be choosen as well + # + #ProxyFactoryClass=org.apache.ojb.broker.core.proxy.ProxyFactoryCGLIBImpl + ProxyFactoryClass=org.apache.ojb.broker.core.proxy.ProxyFactoryJDKImpl + # # The IndirectionHandlerClass entry defines the class to be used by OJB's proxies to # handle method invocations # ! #IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerCGLIBImpl ! IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerJDKImpl # #---------------------------------------------------------------------------------------- *************** *** 213,231 **** RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl # #---------------------------------------------------------------------------------------- # Object cache #---------------------------------------------------------------------------------------- ! # The ObjectCacheClass entry tells OJB which concrete ObjectCache ! # implementation is to be used as standard cache. ! # Its also possible to override this entry adding object-cache elements ! # on jdbc-connection-descriptor level and ! # per class-descriptor in repository file. More info see documentation. ! # ! ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl ! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl ! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl ! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl ! #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl ! # # # This property is only relevant if the per class-descriptor object-cache --- 240,250 ---- RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl # + # #---------------------------------------------------------------------------------------- # Object cache #---------------------------------------------------------------------------------------- ! # NOTE: ObjectCacheClass declaration in OJB.properties file was removed (since OJB 1.0.2). ! # The concrete ObjectCache implementation has to specified in the repository file using ! # the 'object-cache' element. See documentation for more detailed info. # # This property is only relevant if the per class-descriptor object-cache *************** *** 238,266 **** descriptorBasedCaches=false # ! # ! # Use CacheFilters to do filter operations before caching methods were ! # called. Build your own filter class by implementing org.apache.ojb.cache.CacheFilter. ! # It is possible to use a arbitrary number of CacheFilters, but this slows ! # down the performance of the cache, thus handle with care. ! # ! # - org.apache.ojb.broker.cache.CacheFilterClassImpl ! # allows filtering of classes ! # - org.apache.ojb.broker.cache.CacheFilterPackageImpl ! # allows filtering of packages ! # More info see Javadoc of the according classes. ! # Set a comma separated list of CacheFilter. ! #ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl ! # #---------------------------------------------------------------------------------------- # Locking #---------------------------------------------------------------------------------------- ! # The LockManagerClass entry tells OJB which concrete LockManager ! # implementation is to be used. ! LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl # # The LockMapClass entry tells OJB which concrete LockMap # implementation is to be used. # If OJB is running on multiple concurrent clients it is recommended ! # to use the RemoteLockMapImpl. It guarantees to provide # Lockmanagement across multiple JVMs. # This Implemenation relies on a Servlet based Lockserver. To use it you have to --- 257,294 ---- descriptorBasedCaches=false # ! # NOTE: CacheFilters declaration was removed (since OJB 1.0.2). To exclude ! # object of whole packages from being cache use a specific property in ! # cache declaration - see caching guide in reference docs. #---------------------------------------------------------------------------------------- # Locking #---------------------------------------------------------------------------------------- ! # The 'LockManagerClass' specify the internal used LockManager implementation. ! # If OJB is running in distributed environment it is recommended to use the remote ! # lock manager. It guarantees to provide Lockmanagement across multiple JVM's. # + # The deprecated odmg locking implementation. Needs enabled 'LockMapClass' too. + #@deprecated LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl + # A servlet based lock implementation for distributed environments, needs enabled + # property 'LockServletUrl' too. + #LockManagerClass=org.apache.ojb.broker.locking.LockManagerRemoteImpl + # Lock manager implementation using apache's commons-transaction locking api + #LockManagerClass=org.apache.ojb.broker.locking.LockManagerCommonsImpl + LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl + # + # The LockServletUrl entry points to the Lockserver servlet. + # This Servlet is addressed by all distributed JVMs if the RemoteLockMapImpl + # is used. + #LockServletUrl=http://127.0.0.1:8080/ojb-lockserver + # + # The LockTimeout entry defines the maximum time in milliseconds + # that a lock may be hold. Defaults to 60000 = 1 minute + LockTimeout=60000 + # + # + # ------ deprecated ------ # The LockMapClass entry tells OJB which concrete LockMap # implementation is to be used. # If OJB is running on multiple concurrent clients it is recommended ! # to use the LockMapRemoteImpl. It guarantees to provide # Lockmanagement across multiple JVMs. # This Implemenation relies on a Servlet based Lockserver. To use it you have to *************** *** 269,306 **** # (see LockServletUrl section below). # If OJB is running in a single JVM (e.g. in a desktop app, or in a servlet ! # engine) it is save to use the InMemoryLockMapImpl. Using it will result # in a large performance gain. ! #LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl ! LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl ! # ! # The LockTimeout entry defines the maximum time in milliseconds ! # that a lock may be hold. Defaults to 60000 = 1 minute ! LockTimeout=60000 ! # ! # The ImplicitLocking entry defines if implicit lock acquisition is ! # to be used. If set to true OJB implicitely locks objects to ODMG ! # transactions after performing OQL queries. ! # If implicit locking is used locking objects is recursive, that is ! # associated objects are also locked. ! # If ImplicitLocking is set to false, no locks are obtained in OQL ! # queries and there is also no recursive locking. ! ImplicitLocking=true ! #ImplicitLocking=false ! # ! # ! # The LockServletUrl entry points to the Lockserver servlet. ! # This Servlet is addressed by all distributed JVMs if the RemoteLockMapImpl ! # is used. ! LockServletUrl=http://127.0.0.1:8080/ojb-lockserver ! # ! # ! # The LockAssociations entry defines the behaviour for the OJB ! # implicit locking feature. If set to WRITE (default) acquiring a write- ! # lock on a given object x implies write locks on all objects associated ! # to x. If set to READ implicit read-locks are acquired. ! # Acquiring a read-lock on x thus allways results in implicit read-locks ! # on all associated objects. ! #LockAssociations=READ ! LockAssociations=WRITE # # --- 297,305 ---- # (see LockServletUrl section below). # If OJB is running in a single JVM (e.g. in a desktop app, or in a servlet ! # engine) it is save to use the LockMapInMemoryImpl. Using it will result # in a large performance gain. ! # These settings are deprecated, only needed in conjunction with the old odmg 'LockManagerClass' ! # @deprecated LockMapClass=org.apache.ojb.odmg.locking.RemoteLockMapImpl ! # @deprecated LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl # # *************** *** 309,323 **** #---------------------------------------------------------------------------------------- # The OqlCollectionClass entry defines the collection type returned ! # from OQL queries. By default this value is set to DListImpl. ! # This will be good for most situations as DList allows maximum flexibility ! # in a ODMG environment. See also section 'ODMG settings'. # Using DLists for large resultsets may be bad for application performance. # For these scenarios you can use ArrayLists or Vectors. # Important note: the collections class to be used MUST implement the ! # interface org.apache.ojb.broker.ManageableCollection. # ! OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl ! # OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList ! # OqlCollectionClass=org.apache.ojb.broker.util.ManageableVector # # The SqlInLimit entry limits the number of values in IN-sql statement, --- 308,323 ---- #---------------------------------------------------------------------------------------- # The OqlCollectionClass entry defines the collection type returned ! # from OQL queries. By default this value is set to a List. ! # This will be good for most situations. If you need the additional features of ! # DList (DList itself is persistable, support of predicate) comment in the DList ! # implementation. See also section 'ODMG settings' (DListClass entry). # Using DLists for large resultsets may be bad for application performance. # For these scenarios you can use ArrayLists or Vectors. # Important note: the collections class to be used MUST implement the ! # interface 'org.apache.ojb.broker.ManageableCollection'. # ! OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList ! # OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl ! # OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableVector # # The SqlInLimit entry limits the number of values in IN-sql statement, *************** *** 327,331 **** # #---------------------------------------------------------------------------------------- ! # ODMG settings #---------------------------------------------------------------------------------------- # Specify the used base class for ODMG API --- 327,331 ---- # #---------------------------------------------------------------------------------------- ! # ODMG-api settings #---------------------------------------------------------------------------------------- # Specify the used base class for ODMG API *************** *** 337,341 **** #ImplementationClass=org.apache.ojb.odmg.ImplementationJTAImpl # - # # Specify the used tx handling. # - LocalTxManager use if you want the transaction to be associated by a thread --- 337,340 ---- *************** *** 347,350 **** --- 346,379 ---- # # + # The ImplicitLocking entry defines if implicit lock acquisition is + # to be used. If set to 'true' OJB implicitly locks objects to ODMG + # transactions after performing OQL queries. + # Also if implicit locking is used locking objects is recursive, that is + # associated objects are also locked. + # If ImplicitLocking is set to 'false', no locks are obtained in OQL + # queries, lookup objects and there is also no recursive locking. + # This setting can be changed at runtime using OJB's ODMG extensions. + ImplicitLocking=true + #ImplicitLocking=false + # + # The LockAssociations entry defines the behaviour for the OJB + # implicit locking feature. If set to WRITE (default) acquiring a write- + # lock on a given object x implies write locks on all objects associated + # to x. If set to READ implicit read-locks are acquired. + # Acquiring a read-lock on x allways results in implicit read-locks + # on all associated objects (if 'implicit locking' is enabled). + # This setting can be changed at runtime using OJB's ODMG extensions. + #LockAssociations=READ + LockAssociations=WRITE + # + # Enable/Disable OJB's persistent object ordering algorithm on commit + # of a transaction. If enabled OJB try to calculate a valid order for + # all new/modified objects (and referenced objects). + # If the used databases support 'deferred checks' it's recommended to use this + # feature and to disable OJB's object ordering. + # This setting can be changed at runtime using OJB's ODMG extensions. + Ordering=true + # + # # Used ODMG collection implementation classes # (e.g. when do a Implementation#newDlist() call) *************** *** 366,369 **** --- 395,407 ---- # # + # @deprecated property for backward compatibility. + # If set 'true' the behavior of method + # ImplementationImpl#setImplicitLocking(...) will be the same as + # in OJB <=1.0.3 (set the implicit locking behavior of the current used transaction) + # and disable the new possibility of global 'implicit locking' + # setting at runtime with ImplementationExt#setImplicitLocking. + # This is only for backward compatibility and will + # be removed at a later date. + ImplicitLockingBackward=false #---------------------------------------------------------------------------------------- # Meta data / mapping settings *************** *** 394,411 **** # (directly, as a bean, as a dyna bean) and then uses that strategy # ! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImpl #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl ! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanAccessImpl ! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl ! # ! # Here are the new upcoming PersistentField implementations. These classes will replace the ! # 'old' ones on next release. They pass the test-suite, but should be tested by community too. ! # The new implementations are about 50 times faster in handling nested fields. ! PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew ! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImplNew ! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImplNew #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl - #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanImplNew #(DynaBean implementation does not support nested fields) # --- 432,440 ---- # (directly, as a bean, as a dyna bean) and then uses that strategy # ! PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectImpl #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldPrivilegedImpl #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldIntrospectorImpl ! #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDynaBeanImpl #PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldAutoProxyImpl #(DynaBean implementation does not support nested fields) # |
