⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 ojb.properties

📁 一些数据库的java开发编程
💻 PROPERTIES
📖 第 1 页 / 共 2 页
字号:
# 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
# deploy the ojb-lockserver.war into a Servlet engine.
# and you have to set the Property LockServletUrl to point to this servlet.
# (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
#
#
#----------------------------------------------------------------------------------------
# OQL / SQL settings
#----------------------------------------------------------------------------------------
# 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,
# -1 for no limits. This hint is used in Criteria.
SqlInLimit=200
#
#
#----------------------------------------------------------------------------------------
# ODMG-api settings
#----------------------------------------------------------------------------------------
# Specify the used base class for ODMG API
# - ImplementationDefaultImpl is the default class
# - ImplementationJTAImpl is for use in managed environments like J2EE conform
# Application Server
#
ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
#ImplementationClass=org.apache.ojb.odmg.ImplementationJTAImpl
#
# Specify the used tx handling.
# - LocalTxManager use if you want the transaction to be associated by a thread
# - JTATxManager use if you want the transaction to be associated via the Transaction
# manager that is in your application server.
#
OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
#OJBTxManagerClass=org.apache.ojb.odmg.JTATxManager
#
#
# Specify the cascading delete behavior of the odmg-api. The
# specified settings will be used by odmg-api as default settings. It
# is also possible to change these settings at runtime using the
# TransactionExt#setCascadingDelete method.
#
# Enable disable cascading delete for 1:1 references
cascadingDeleteOneToOne=false
#
# Enable disable cascading delete for 1:n references
cascadingDeleteOneToN=false
#
# Enable disable cascading delete for m:n references
cascadingDeleteMToN=false
#
#
# 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 and lookup objects.
# 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.
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 thus allways results in implicit read-locks
# on all associated objects.
#LockAssociations=READ
LockAssociations=WRITE
#
#
# Used ODMG collection implementation classes
# (e.g. when do a Implementation#newDlist() call)
#
# org.odmg.DList implementation class
DListClass=org.apache.ojb.odmg.collections.DListImpl
#
# org.odmg.DArray implementation class
DArrayClass=org.apache.ojb.odmg.collections.DListImpl
#
# org.odmg.DMap implementation class
DMapClass=org.apache.ojb.odmg.collections.DMapImpl
#
# org.odmg.DBag implementation class
DBagClass=org.apache.ojb.odmg.collections.DBagImpl
#
# org.odmg.DSet implementation class
DSetClass=org.apache.ojb.odmg.collections.DSetImpl
#
#
#----------------------------------------------------------------------------------------
# Meta data / mapping settings
#----------------------------------------------------------------------------------------
# The PersistentFieldClass property defines the implementation class
# for PersistentField attributes used in the OJB MetaData layer.
# By default the best performing attribute/refection based implementation
# is selected (PersistentFieldDirectAccessImpl).
#
# - PersistentFieldDirectAccessImpl
#   is a high-speed version of the access strategies.
#   It does not cooperate with an AccessController,
#   but accesses the fields directly. Persistent
#   attributes don't need getters and setters
#   and don't have to be declared public or protected
# - PersistentFieldPrivilegedImpl
#   Same as above, but does cooperate with AccessController and do not
#   suppress the java language access check (but is slow compared with direct access).
# - PersistentFieldIntrospectorImpl
#   uses JavaBeans compliant calls only to access persistent attributes.
#   No Reflection is needed. But for each attribute xxx there must be
#   public getXxx() and setXxx() methods.
# - PersistentFieldDynaBeanAccessImpl
#   implementation used to access a property from a
#   org.apache.commons.beanutils.DynaBean.
# - PersistentFieldAutoProxyImpl
#   for each field determines upon first access how to access this particular field
#   (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 and be tested the last months.
# 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)
#
#----------------------------------------------------------------------------------------
# Component Intercepting for Profiling and Tracing
#----------------------------------------------------------------------------------------
# By enabling an InterceptorClass all OJB components will use
# this Interceptor. Interceptors allow advanced tracing and Profiling
# of all component method calls.
# This is currently an experimental feature useful only for OJB kernel developers.
#
#InterceptorClass=org.apache.ojb.broker.util.interceptor.TracingInterceptor
#
#----------------------------------------------------------------------------------------
# Transaction Management and assocation
#----------------------------------------------------------------------------------------
# (optional, only used when OJB runs within managed environments)
# To praticipate in JTA transaction OJB needs access to the underlying transaction manager.
# The TransactionManager is acquired in different ways dependent on the application server.
# The JTATransactionManagerClass property allows you to specify the class that implements
# the proper behaviour for finding the transaction manager. Only use when OJBTxManagerClass
# is set to a factory that uses the application server transaction manager
# (org.apache.ojb.odmg.JTATxManager)
#
# JBoss Transaction Manager Factory
JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
# Weblogic Transaction Manager Factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WeblogicTransactionManagerFactory
# WebSphere transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.WebSphereTransactionManagerFactory
# Orion transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.OrionTransactionManagerFactory
# SunOne transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.SunOneTransactionManagerFactory
# JOnAs transaction manager factory
#JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JOnASTransactionManagerFactory
#
#
#----------------------------------------------------------------------------------------
# Logging settings are now in their own file, OJB-logging.properties
#----------------------------------------------------------------------------------------
#----------------------------------------------------------------------------------------
# End of OJB.properties file
#----------------------------------------------------------------------------------------

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -