Table 6-1 Support for Lazy Loading by Mapping Type Mapping Table 6-1 lists support for lazy loading by mapping type. When you set the attribute to lazy, the EclipseLink JPA persistence provider uses indirection. The collection annotations and provide a fetch mapping attribute which can be set to lazy or eager. If you set one-to-one or many-to-one relationships to lazy, and you enable weaving, the EclipseLink JPA persistence provider will use weaving to enable value holder indirection for these relationships. When using a one-to-one or many-to-one mapping in a Java SE environment and the environment does not permit the use of -javaagent on the JVM command line, use static weaving to perform lazy loading when the fetch attribute is set to FetchType.LAZY. Also in the Java SE environment, one-to-many and many-to-many relationships are lazy by default and use transparent indirection, while one-to-one and many-to-one relationships are not lazy. When using a one-to-one or many-to-one mapping in a Java SE environment, use either dynamic or static weaving to perform lazy loading when the fetch attribute is set to FetchType.LAZY. If you are developing your application in a Java EE environment, set fetch to, and the persistence provider supplies all the necessary functionality. JPA specifies that lazy loading is a hint to the persistence provider that data should be fetched lazily when it is first accessed, if possible. For a one-to-many using a JoinTable, the deletion of the join table is cascaded on the database (target objects cannot be cascaded even if private because of constraint direction).įor more information, see Section 11.1.23 "JoinTable Annotation" in the JPA Specification. For a one-to-many using a mappedBy or JoinColumn, the deletion of the related objects is cascaded on the database. Required when multiple mappings share the same database column.Ĭonverters: Allows custom data types and data conversions to be used with most mapping typesįor more information on these annotations, see Java Persistence API (JPA) Extensions Reference for EclipseLink.īy default, JPA automatically defines a OneToMany mapping for a many-valued association with one-to-many multiplicity.Ĭonfigure the associated target entity, because the Collection used is not defined using genericsĬonfigure the operations that must be cascaded to the target of the association: for example, if the owning entity is removed, ensure that the target of the association is also removedĬonfigure the details of the join table used by the persistence provider for unidirectional one-to-many relationships. Read-Only: Specifies that the mapping should populate the value on read and copy. Use the following annotations to fine-tune how your application implements these Basics (See Using Indirection with Collections)įor all mapping types there are a common set of options: Mappings of simple Java types are called basic mappings.īy default, the EclipseLink persistence provider automatically configures a basic mapping for simple types. Simple Java types are mapped as part of the immediate state of an entity in its fields or properties. If weaving is used on the server, and the entities are serialized to a client, the same weaved classes must exist on the client, either through static weaving of the jar, or through launching the client JVM using the EclipseLink agent.įor more information, see Using Java Byte-code Weaving. When serializing JPA entities, any lazy relationships that have not been instantiated prior to serialization will trigger errors if they are accessed. Use caution for objects with many or deep relationships to avoid serializing large object graphs: ideally, only the relationships required by the client should be instantiated. If the application desired the relationships to be always instantiated on serialization, you could overwrite the serialization writeObject method in the persistent class to first instantiate the desired relationships. This can be done through accessing the get method for any relationship using ValueHolder or weaved indirection, and by calling the size method to any relationship using transparent indirection. The application must ensure that any indirect relationships that will be required after deserialization have been instantiated before serialization. Because indirection objects are transient and do not survive serialization between one JVM and another, untriggered indirection objects will trigger an error if the relationship is accessed after deserialization. When using indirection (lazy loading), it is likely that a graph of persistent objects will contain untriggered indirection objects. Indirection, Serialization, and Detachment
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |