An entity bean using container-managed persistence delegates the management of its state or persistence to the Sun Java System Application Server container. The deployment descriptors then provide the information that the container uses to map bean fields to columns in a relational database.
Unlike bean-managed persistence, container-managed persistence does not require you to write database access calls in the methods of the entity bean class. Because persistence is handled by the container at runtime, you must specify in the deployment descriptor those persistence fields and relationships for which the container must handle data access.
You access persistent data using the accessor methods that are defined for the abstract persistence schema. An entity bean that uses container-managed persistence consists of several components that interoperate:. This class inherits from the abstract bean class and uses information from the deployment descriptor.
Accessor read and mutator write methods in the bean class are implemented here to the concrete state class. This section applies only if you are using container-managed persistence 2. A relationship allows you to navigate from an object to its related objects.
Relationships can be either bidirectional or unidirectional. Even if a relationship is unidirectional, if you make a change to that relationship, other enterprise beans will be affected if they are associated with that relationship. A container - managed relationship CMR between fields in a pair of classes allows operations on one side of the relationship to affect the other side. At runtime, if a field in one instance is modified to refer to another instance, the referred instance will have its relationship field modified to reflect the change in relationship.
No warning is given if you delete one object in a managed relationship. Container-managed persistence automatically nullifies the relationship on the foreign key side and deletes the object without asking for confirmation. In the Java code, relationships are represented by object reference either collections or fields that are typed to an EJB local interface , depending on the relationship cardinality.
A relationship can be one-to-one, one-to-many, or many-to-many, depending on the number of instances of each class in the relationship. In the database, this might be represented by foreign key columns and, in the case of many-to-many relationships, join tables.
With one-to-one relationships, there is a single-valued field in each class whose type is the local interface of the other bean type.
Any change to the field on either side of the relationship is handled as a relationship change. If the field on one side is changed from null to non-null, then the field on the other side is changed to refer to this instance. If the field on the other side had been non-null, that other relationship is made null before the change is made.
With one-to-many relationships, there is a single-valued field on the many side and a multi-valued field collection on the one side. If an instance is added to the collection field, the field in the new instance is updated to reference the instance containing the collection field. If an instance is deleted from the collection, the field on the instance is nullified. Any change, addition or removal of a field on the many side is handled as a relationship change.
If the field on the many side is changed from null to non-null, this instance is added to the collection-valued field on the one side. If the field on the many side is changed from non-null to null, then this instance is removed from the collection-valued field on the one side. With many-to-many relationships, there are multi-valued, or collection , fields on both sides of the relationship.
Any change to the contents of the collection on either side of the relationship is handled as a relationship change. If an instance is added to the collection on this side, then this instance is added to the collection on the other side.
If an instance is removed from a collection on this side, then this instance is removed from the collection on the other side. Part of an entity bean's deployment descriptor, the abstract schema defines the bean's persistent fields and relationships. The term abstract distinguishes this schema from the physical schema of the underlying data store. You specify the name of an abstract schema in the deployment descriptor. If your container-managed fields are to be mapped to database fields, you must provide mapping information to the deployer.
Each module with container-managed persistence beans must have the following files for the deployment process. In the Sun Java System Application Server, the container-managed persistence model is based on the Pluggable Persistence Manager API which provides the role of the persistence manager in defining and supporting the mapping between an entity bean and the persistence store.
The persistence manager is the component responsible for the persistence of the entity beans installed in the container. The classes provided by the persistence manager vendor are responsible for managing the relationships between the entity beans, and for managing access to their persistent state.
The persistence manager vendor is also responsible for providing the implementation of the Java classes that are used in maintaining the container-managed relationships. The persistence manager uses the data source registry provided by the container to access data sources. The following figure illustrates how persistence works in the Sun Java System Application Server environment. It is also possible to write custom persistence managers to support legacy systems, or to implement caching strategies that improve performance for your container-managed persistence solution.
Java types assigned to the container-managed fields must be restricted to the following: Java primitive types, Java serializable types, and references to EJB remote or remote home interfaces. The container-managed persistence process consists of three operations: mapping, deploying, and running. These operations are accomplished as described in the following phases:. This phase can be done concurrent with development of the container-managed persistence beans in the Sun ONE Studio 5 IDE, or after development while preparing for deployment.
A primary table is selected for each container-managed persistence bean, and optionally, multiple secondary tables. CMP fields are mapped to columns in either the primary or secondary table s. CMR fields are mapped to pairs of column lists normally, column lists are the list of columns associated with pairs of primary and foreign keys. There is no automatic procedure for performing this remapping; you must do it manually.
During this phase, deployment information is combined with the mapping information created during Phase 1. This file contains the container-managed persistence query parameter list, the query filter, the query ordering expression, the query candidate class name, and the query result type. At runtime, the information provided at deployment is used to service requests on entities implemented as enterprise beans.
Mapping refers to the ability to tie an object-oriented model to a relational model of data, usually the schema of a relational database. The container-managed persistence implementation provides the ability to tie a set of interrelated classes containing data and associated behaviors to the interrelated meta-data of the schema. You can then use this object representation of the database to form the basis of a Java application.
You can also customize this mapping to optimize these underlying classes for the particular needs of an application. The result is a single data model through which you can access both persistent database information and regular transient program data. You only need to understand the Java programming language objects; you do not need to know or understand the underlying database schema. This mapping information is stored in an XML file. The meet-in-the-middle mapping of the container-managed persistence implementation creates a custom mapping between an existing schema and existing Java classes, using the Mapping Tool.
A container-managed persistence class should represent a data entity, such as an employee or a department. To model a specific data entity, you add persistent fields to the class that correspond to the columns in the data store. An Employee class, for example, would have persistent fields for all the columns found in the EMPLOYEE table of the data store, such as lastname , firstname , department , and salary.
You can choose to have only a subset of the data store columns used as persistent fields, but if a field is persistent, it must be mapped. Container-managed persistence supports a set of JDBC 1. Supported JDBC 1. BLOBs are binary or serializable objects, such as pictures, that translate into large byte arrays which are then serialized into CMP fields.
On Oracle, using the Oracle thin driver JDBC type 4 , it is not possible to insert more than bytes of data into a column. Mapping information is developed by first capturing the database schema. Use the capture-schema command to store the database metadata schema in a file for use in mapping and execution. These privileges are granted to the user by the database administrator. The capture-schema utility does not modify the schema in any way.
Its only purpose is to provide the persistence engine with information about the structure of the database the schema. If not specified, the default will capture metadata for all tables from all the schemas accessible to this user. If more than one schema is accessible for this user, more than one table with the same name might be captured, which will cause problems if this parameter is not set.
Multiple table names can be specified. If not specified, all the tables in the database schema will be captured. Defaults to stdout. To be able to use the output for the CMP mapping, the output file name must have the. In the sun-cmp-mappings. Any help and hints are greatly appreciated. Community Bot 1 1 1 silver badge. Jbartmann Jbartmann 1, 4 4 gold badges 22 22 silver badges 39 39 bronze badges. Have you tried specifying the unitName optional property on your PersistenceContext annotation?
OK, just checking. It's not supposed to be needed unless there's more than one persistence unit. The persistence. Is that the case? As I just discovered it is not, but it should be. Add a comment.
Active Oldest Votes. A couple of possible issues: Incorrect location of the persistence. Invalid persistence. Demecki G. Demecki 9, 2 2 gold badges 55 55 silver badges 56 56 bronze badges. Thank you this helped me a lot! I just did not see things like this anymore after searching for a solution for hours! Normally this happens when the method javax. The method javax. Its restrictive as in it allows for one and only one record to be fetched as part of its call. In case there is no result obtained on running the query and a getSingleResult method is executed then a javax.
Flag that specifies whether to interpret quoted numbers in query strings as numbers, as opposed to strings. Set to true to mimic the behavior of Kodo 3. Range of values : none read write numeric values for lock manager- specific lock levels.
Sets the default read level at which to lock objects retrieved during a non-optimistic transaction. Range of values : none clear. Specifies the amount of time to wait in milliseconds before attempting to reconnect to a peer of the cluster when connectivity to the peer is lost. Specifies a semicolon-separated list of resource paths to metadata files or jar archives. Flag that specifies whether to restore managed fields to their pre-transaction values when a rollback occurs.
The object becomes hollow and will reload its state the next time it is accessed. Range of values : forward--only scroll-sensitive scroll-insensitive. Specifies the JDBC result set type to use when fetching return lists. This setting can also be varied at runtime. The result set is not updatable. The result set is updatable. Flag that specifies whether persistent fields retain their values on transaction commit.
This element defaults to true when a child element of the persistence-configuration-unit and false when a child element of the kodo-broker element. Flag that specifies whether to log a warning and defer registration instead of throwing an exception when a persistent class cannot be fully processed. This element should only be used in complex classloader situations where security is preventing Kodo from reading registered classes. Setting this to true unnecessarily may obscure more serious problems.
Flag that specifies whether to search for metadata files top-down in the package tree. Kodo defaults to bottom-up scanning. For example, when scanning metadata for class C , Kodo looks first for C. Specifies the default schema name to prepend to unqualified table names. In addition, specifies the schema in which Kodo creates new tables. Specifies the name of the table's string column for holding the schema definition as an XML string. Specifies the name of the database sequence. Specifies the name of the column that holds the current sequence value.
Configures the Kodo datasource implementation. This lock manager uses in-memory mutexes to obtain exclusive locks on object ids. It does not perform any database-level locking. Also, it does not distinguish between read and write locks; all locks are write locks. Sets the number of soft references that Kodo maintains. When the maximum cache or query size is reached, random entries are moved to a soft reference map so that they are maintained for awhile longer.
By default, this value is set to -1 which specifies that an unlimited number of soft references are maintained. Set the property to 0 to disable soft references. Specifies the socket read timeout in milliseconds. The sql-server-dictionary element shares the same subelements as access-dictionary, plus the following subelements defaults shown :.
Provider examines the current thread's stack and builds an execution context name based on that information. Flag that specifies whether to require identity values used for finding application identity instances to be of the exact right type.
By default, Kodo allows stringified identity values, and performs conversions between numeric types. Range of values : line partial full. Provider examines the current thread's stack and builds an execution context name based on that information and the following setting:. Specifies the method to use to select subclass data when it is in other tables. For a description of the valid values, see under eager-fetch-mode.
Configuration values for the Sybase Dictionary persistence plugin. The sybase-dictionary element shares the same subelements as access-dictionary, plus the following subelements defaults shown :. Flag that specifies whether to sync with managed transactions. Controls whether Kodo attempts to run the mapping tool on all persistent classes to synchronize their mappings and schema at runtime.
This element save you the trouble of running the mapping tool manually, and is useful for rapid test and debug cycles. Specifies the name of the table. The default value depends on the parent element:. If the table does not already exist, it is created the first time you run the mapping tool's on a class that requires it.
This setting is valid for JDO 2. Defines an update manager capable of statement batching, that ignores foreign keys and auto-increment, but optimizes for table level locking. This is useful when using table-level locking and trying to avoid deadlocks. This schema factory stores schema information as an XML document in a database table it creates for this purpose.
If your JDBC driver doesn't support the java. DatabaseMetaData standard interface, but you still want some schema validation to occur at runtime, you might use this factory.
It is not recommended for most users, though, because it is easy for the stored XML schema definition to get out-of-sync with the actual database. Name of the Tangosol Coherence cache to use. Range of values : named distributed replicated. This method looks up the cache by the name as defined in the Coherence configuration. Integrates with Tangosol's Coherence caching system. Configures the TCP remote commit provider. Specifies the transport layer for the remote communication.
This type uses an in-memory static counter, initialized to the current time in milliseconds and monotonically incremented for each value requested. It is only suitable for single-JVM environments. Specifies the topic to which the remote commit provider should publish notifications and subscribe for notifications sent from other JVMs. Specifies the JNDI name of a javax. TopicConnectionFactory factory to use for finding topics. This setting may vary depending on the application server in use; consult the application server's documentation for details about the default JNDI name for the topic instance.
Flag that specifies whether to use smart proxies. Range of values : default none read-committed read-uncommitted repeatable-read serializable. Provider returns the current transaction's name, as defined by WebLogic transaction naming semantics.
Specifies the type of generator. Range of values : 0 1 2 3. Specifies a semicolon-separated list of fully-qualified persistent class names. URL to which Kodo should connect to access the remote server. Specifies a semicolon-separated list of URLs of metadata files or jar archives. Flag that specifies whether to use each class' entity name as the primary key value of each row rather than the full classname.
Flag that specifies whether to return hollow objects objects for which no state has been loaded from calls to PersistenceManager. This is the default behavior of Kodo 4. Previous Kodo versions, however, always loaded the object from the datastore. Set this property to false to get the old behavior. Flag that specifies whether to check the datastore to be sure the given oid exists. Prior to Kodo 4. Kodo 4.
Set this property to true to mimic previous behavior. This Seq is like the table-jdbc-seq, but has an arbitrary number of rows for sequence values, rather than a fixed pattern of one row per class. Specifies whether to perform version checking and incrementing behavior of the pessimistic lock manager on read operations. Specifies whether to perform version checking and incrementing behavior of the pessimistic lock manager on write operations. This lock manager does not perform any exclusive locking, but instead ensures read consistency by verifying that the version of all read-locked instances is unchanged at the end of the transaction.
Furthermore, a write lock will force an increment to the version at the end of the transaction, even if the object is not otherwise modified. This ensures read consistency with non-blocking behavior. Supports optional parameters in the Management Group and WebLogic 8. Range of values : none read write numeric values for lock-manager specific lock levels.
Sets the default write level at which to lock objects retrieved during a non-optimistic transaction. C Oracle Kodo Persistence Configuration Schema Reference This appendix describes the namespace, schema location, file structure, and elements in the Kodo-specific deployment descriptor, persistence-configuration.
Customers are encouraged to consider using Oracle TopLink. Example The default values for each of the configuration values are shown in the example below.
Valid options include: warn —Log a warning. Valid values include: datastore 0 —Clear object field values when entering a datastore transaction. When specified as a child of the auto-detaches element, valid event types include: close 0 —Detach all objects when the PersistenceManager closes. Runtime Parent elements : persistence-configuration persistence-configuration-unit Function Specifies the channel to which you want to log.
The following provides sample values: COM. DbcpDriver COM. DB2Driver centura. SqlbaseDriver com. DB2Driver com. OracleDriver com. SQLServerDriver com. SybaseDriver com. MsqlDriver com. TdsDriver com. IfxDriver com.
Driver com. JSQLDriver com. JDBCDriver com. DatabaseMetaData com. DriverSapDB com. SybDriver com. Driver in. DaffodilDBDriver interbase. Driver intersolv. SequeLinkDriver openlink. Driver oracle. OracleDriver oracle. OracleDataSource org. AxionDriver org. Driver org. PGDriver postgresql. Driver solid. SolidDriver sun. JdbcOdbcDriver weblogic. Driver weblogic. Valid options include: local —Specifies a standard data source under Kodo control. Example The db2-dictionary element shares the same subelements as "access-dictionary".
Valid values include: FIELD —Injects state directly into your persistent fields, and retrieves changed state from your fields as well.
0コメント