You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by hm...@hotmail.ru on 2008/01/26 11:01:08 UTC

Re[2]: Problems running Cayenne ORM Tier and CWS Client Tier on the same JVM.

Hi, Andrus!

What i understood from chapter 'Running Client Without CWS' at the "http://cayenne.apache.org/doc/remote-object-persistence-coding-client.html" page is that i can use data from the same library of my ObjEntity classes (actually generated client classes) through not only remote source channel (HessianConnection) but also through local source channel (LocalConnection). I think the only reason i would need standart Cayenne classes is if i need my application work faster.
This mixing would be the most reasonable if i have a Web application and desktop swing application working with same set of entities (with one database). Then i wouldn't need to generate TWO packages of classes representing one set of db entities. Also they together might work faster, because they would use the same cache.
Well, this dream could come true only if both 'applications' use the same Configuration. So i also thought that Configuration.getSharedConfiguration() returns something other than the conf CWS is using. Now that you say that CWS creates its own configuration and stores  it in the application-scoped object, i ask: how then i can fetch this Configuration?? 
What about my project, as you've already figured out, i'm currently using JBoss, but this is just for a test, and soon i'm going to get rid of jboss and use simple Tomcat. So probably it will work better on it?
As of my persistent classes, yes, i have standard and client classes compiled together in the same JAR. I've just generated them with CayenneModeler and done nothing else. The "com.nic.porshe.clc" package is for Cayenne client classes but i also have "com.nic.porshe.cc" package for Cayenne standard classes. I can send you those classes and cayenne.xml project, if it will help.

What is really strange, is why everything works with HESSIAN_SERIALIZATION and does not with JAVA_ and NO_.

P.S. while writing this message, i thought that maybe client classes are developed to work with HESSIAN_SERIALIZATION only. If this is so, you should definitely mention it in your documentation. 
I've done some simple fetching time tests and CWS&LocalConnection&HESSIAN_SERIALIZATION's architecture work time is somewhere in the middle between CWS&HessianConnection's and simple Cayenne's. So i still can use it, although this is not the result i expected to get with NO_SERIALIZATON.

Thanks Andrus, and i'm really looking forward to your answer,

Andrey


Пт, 25.01.2008 17:23:26 you wrote:
>
AA> 
AA> Hmm... I think this maybe causing the problem:
AA> 
AA> Configuration.getSharedConfiguration().getDomain();
AA> 
AA> Not sure if JBoss messes up the static Configuration.. CWS is not  
AA> using a static Configuration, instead it creates its own, and stores  
AA> it in the application-scoped object. Maybe you can do something like  
AA> that too? E.g. initialize DefaultConfiguration instance and store it  
AA> in a ServletContext (if that's applicable for your environment)....
AA> 
AA> Andrus
AA> 
AA> 
AA> On Jan 25, 2008, at 2:09 PM, Andrus Adamchik wrote:
AA> 
AA> > Hi Andrey,
AA> >
AA> > the most efficient way to use LocalConnection is with  
AA> > LocalConnection.NO_SERIALIZATION, and this is certainly the way to  
AA> > go if you are to instantiate the ROP stack in the same JVM as the  
AA> > server.
AA> >
AA> > So regarding the exception - what are the server and client classes  
AA> > mapped for the Uchgroup entity?
AA> >
AA> > Thanks,
AA> > Andrus
AA> >

Re: Re[2]: Problems running Cayenne ORM Tier and CWS Client Tier on the same JVM.

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jan 26, 2008, at 11:01 AM, <hm...@hotmail.ru> <hm...@hotmail.ru>  
wrote:

>
> What i understood from chapter 'Running Client Without CWS' at the "http://cayenne.apache.org/doc/remote-object-persistence-coding-client.html 
> " page is that i can use data from the same library of my ObjEntity  
> classes (actually generated client classes) through not only remote  
> source channel (HessianConnection) but also through local source  
> channel (LocalConnection). I think the only reason i would need  
> standart Cayenne classes is if i need my application work faster.

I see, we should probably remove the first example there (the one  
without a LocalConnection), as we are currently not testing such setup  
and can't guarantee that it works.

> This mixing would be the most reasonable if i have a Web application  
> and desktop swing application working with same set of entities  
> (with one database). Then i wouldn't need to generate TWO packages  
> of classes representing one set of db entities. Also they together  
> might work faster, because they would use the same cache.
> Well, this dream could come true only if both 'applications' use the  
> same Configuration. So i also thought that  
> Configuration.getSharedConfiguration() returns something other than  
> the conf CWS is using. Now that you say that CWS creates its own  
> configuration and stores  it in the application-scoped object, i  
> ask: how then i can fetch this Configuration??

You can subclass HessianService and expose its DataDomain protected  
variable to the application in a way that is appropriate for your  
app.. E.g. via a static method.  Your custom subclass name can be  
passed to HessianServlet via "service-class" init parameter in  
"web.xml".

> What is really strange, is why everything works with  
> HESSIAN_SERIALIZATION and does not with JAVA_ and NO_.

Hmm... Yesterday I didn't realize that it worked for you with  
HESSIAN_SERIALIZATION *locally*... Now it is starting to make sense...  
I think this is due to the transient variables in some objects  
involved. During serialization they are being reset to NULL, while  
NO_SERIALIZATION leaves them in the "client state". I am still unsure  
about HESSIAN vs. JAVA though...

Anyways, let me open a bug in Jira, and please use  
HESSIAN_SERIALIZATION for now.

Thanks,
Andrus