Hi,
I believe that the specification wording "Serializing entities and
merging those entities back into a persistence context " refers to
two independent operations: serializing and merging. It's possible to
commit a tx from em1 thereby disconnecting the entity and merge the
entity into em2 from the same provider, but not necessarily a
different one. It's a different use case to serialize to a different
vm where the same provider is available. The way I understand the
spec wording, these are two different use cases.
On Dec 5, 2006, at 3:40 PM, Gordon Yorke wrote:
> Hello Sahoo,
> I agree that this is a valuable usecase but is limited by the
> current wording of the specification. Perhaps Mike or Linda can
> voice the intentions of the spec here but I do not believe the
> serialization specifics were intended to apply only to when the
> serialized objects would be used for merging. Without a mechanism
> for the user to tell the Persistence Provider about the target
> environment the Persistence Provider has to assume that the
> entities are being serialized to the vendor's environment in order
> to be compliant with the sections of the specification mentioned
> below. Including API for the user to use to notify the Persistence
> Provider of the target environment is a viable option that has been
> mentioned before but would be outside other specification an in
> order to proceed on this issue this is the approach we should take.
It's not clear to me that this is the approach to take. I'd like to
explore how to make the provider accept the serialized classes on the
other end of the server. I'd like to give the users choice how to
proceed: choose one of a) pre-weave the classes on the client side;
b) install TopLink classes on the client and use the appclient
environment to dynamically weave the classes based on annotations; c)
install TopLink classes on the client and use the appclient
environment to dynamically weave the classes based on a suitable
persistence.xml; d) install the TopLink agent on Java SE client to
dynamically weave the classes based on annotations (or
persistence.xml as in c).
more comments below...
> --Gordon
>
> Sanjeeb Kumar Sahoo wrote:
>> Hi,
>>
>> This is a fairly important issue and please excuse me for the
>> rather long email. Since we could not reach at a conclusion on
>> this issue during our phone conversation, we agreed to start an
>> email discussion. For the benefits of those who were not part of
>> our phone discussion, here is a brief back ground:
>>
>> Use case:
>> ------------
>> There is a remote business interface called Facade which returns a
>> JPA entity type object City in a business method. The remote
>> interface and the entity class definition is shown here:
>> @Remote
>> public interface Facade {
>> City getCityById(int cityId);
>> }
>>
>> @Entity
>> public class City implements Serializable {
>> private int id;
>> private Region region;
>>
>> @Id @GeneratedValue(strategy = GenerationType.AUTO)
>> public int getId() {...}
>> public void setId(int id) {...}
>>
>> @ManyToOne(fetch = FetchType.LAZY)
>> public Region getRegion() {...}
>> public void setRegion(Region region) {...}
>> ...
>> }
>>
>> The ear file is packaged like this:
>> ear
>> lib/common.jar (contains City.class, Region.class, Facade.class.)
>> ejb.jar (contains FacadeBean.class and persistence.xml)
>> appclient.jar (contains Client.class)
>>
>>
>> As you can see from the above packaging structure, the persistence
>> unit (PU) is scoped to the ejb module and client is using the
>> entity classes as POJOs. For the client, they represent data
>> transfer objects (DTOs) while accessing the session bean's remote
>> business interface.
>>
>> The bug: (https://glassfish.dev.java.net/issues/show_bug.cgi?id=1081)
>> -----------
>> When client calls the business method of the bean, it gets an
>> exception during unmarshaling. The exception message reads
>> something like this:
>> Caused by: java.io.IOException: Mismatched serialization UIDs :
>> Source
>>
>>
>> Root cause:
>> ---------------
>> The above exception is caused by the fact that TopLink Essential,
>> in order to support lazy loading, has enhanced the classes in the
>> EJB container in a such way that the client can't deserialize them
>> using the original class
This is perfectly fine.
>> even though the appclient container has TopLink Essential classes
>> in it's classpath.
It's not clear what this means. Clearly, it's possible for TopLink to
enhance the classes on the client; we just need to decide the mechanism.
>>
>> I do feel that it is a supported portable use case, but there were
>> two other kinds of opinions, viz:
>> 1) It is a supported use case, but appclient container should
>> somehow enhance the class so that it can be deserialized.
>> 2) It is not a supported use case, client must define persistence
>> unit so that class can be enhanced.
>>
>> As you can see, there is a subtle difference between #1 & #2. Even
>> though #1 makes it transparent, it requires the client to have
>> access to the same persistence provider runtime as the server. Is
>> this a reasonable expectation?
Yes. Or the provider's offline enhancer must be used to enhance the
serialized classes.
>> Shouldn't a JBoss appclient be allowed to call an EJB deployed in
>> GlassFish without having to require GlassFish classes in JBoss
>> client container?
No. As I understand it, an appclient is not required to interoperate
with another server implementation.
>>
>> #2 requires client to have access to persistence.xml. If I
>> remember correctly, the primary reason to require persistence.xml
>> was that container can assume JPA annotated entity classes being
>> used as client view classes in a Java EE environment in the
>> absence of persistence.xml.
>>
>> Here is what I find in the spec:
>> 1. section #2.1:
>> If an entity instance is to be passed by value as a detached
>> object (e.g., through a remote interface), the entity class must
>> implement the Serializable interface.
>>
>> 2. section #3.2.4.2 (Detached Entities and Lazy Loading):
>> Serializing entities and merging those entities back into a
>> persistence context may not be interoperable across vendors when
>> lazy properties or fields and/or relationships are used.
>> A vendor is required to support the serialization and subsequent
>> deserialization and merging of detached entity instances (which
>> may contain lazy properties or fields and/or relationships that
>> have not been fetched) back into a separate JVM instance of that
>> vendor's runtime, where both runtime instances have access to the
>> entity classes and any required vendor persistence implementation
>> classes.
>> When interoperability across vendors is required, the application
>> must not use lazy loading.
>>
>> Please note that the above section clearly talks about merging the
>> detached object in a separate JVM, which is not attempted by the
>> client in our example. It just calls the session bean to get the
>> entity and it has no intention to access the lazy fields.
>>
>> IMHO, requiring that JPA classes that do not have lazy attributes
>> can only be portably used in remote interface will be a serious
>> limitation.
I think you meant "requiring that only JPA classes that do not have
lazy attributes can be portably used in remote interface will be a
serious limitation." And I believe that this is exactly the
limitation envisioned by the spec writers. The only way around this
is to specify the enhancement contract as JDO did.
>> It throws away the big promise that JPA entity classes can be used
>> as DTOs because in reality many entities have lazy attributes. I
>> always thought the spec even allowed the client to access the lazy
>> fields as long as it is populated by the server. It is a contract
>> between the server and client developer. If the lazy fields have
>> not been populated by the server, client can't access them.
I believe that there is value in a provider enhancing serialized
classes in a way that guarantees that if an unloaded lazy field is
accessed, then an exception is thrown. And therefore, there is value
in a non-portable serialized class format. Which means there is value
in dynamically enhancing the class on the client side. And our focus
should be on giving users options on how to accomplish this.
Craig
>>
>> Thanks,
>> Sahoo
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!
- application/pkcs7-signature attachment: smime.p7s