François,
thank you for clearing that point. Indeed, we had a misunderstanding. I will try to
clear this point:
I talked of both, server caching and client caching.
With server caching I mean what you wrote below: managing the dirty flag
automatically. I understand what you write and so I
have to wait for EJB 2.0 implementation in JOnAS to enjoy this. The other solution
would be to make the container to hold
"clean" values: After ejbLoad, ejbCreate and ejbStore these are filled with the
current values. ejbStored does write back
data to the DMBS only if one of the current values differ from it's intial value. This
is not quite complicated to write, and
even the many .equals that are to call in ejbStore, this should be faster than
physical writing -> there should be
performance benefits. And this should be working, even with the user making changes
directly on the fields!
With client caching I do NOT mean caching in the client application, but caching in
the RMI client stub. My idea was, if
there is a proxy on the client (which is the RMI stub), and the application talks to
that proxy in any case (because RMI
wants the application to do so), it should be possible to change that proxy to not
always make TCP calls to the server if a
client wants to getXXX or setXXX, but to think over first if this is needed. If it is
not needed (same getXXX many times in
the same transaction -> because of transaction consistency there cannot be any changed
data), the data is taken from a cache,
and is not recalled from the server's cache. A setXXX is checked if it really sets new
data (setA(1) does not need to be
transmitted to the server, if the current value of field A already is 1). I do not see
that this would lead to problems. I
only talk of CMP entity beans running in a transactional context.
> Hello Markus,
>
> I think we have a misunderstanding about what we call
> "client caching". For me, client caching is caching data in the
> "EJB client" application side, which is currently not achieved
> since EJB clients manipulate "remote references" to the EJB
> objects containing the data, in the EJB server. So the cache
> is maintained in the EJB server.
> I read at least one article about client caching, but the proposed
> solution was quite not satisfying, leading to some uncoherency problems...
> Anyway I think that what you are speaking about is caching data
> in the EJB instances (achieved by the container in the EJB server). This
> caching is already done in the scope of a transaction. To maintain this
> cache across transactions we have the dirty flag which should
> be currently "manually" positionned, since in EJB1.1, any method can
> modify a CMP field. In EJB 2.0, getXXX and setXXX methods will be
> generated, and setXXX will be the only
> way to modify the XXX CMP field, thus the dirty flag will be managed
> automatically. So I 'm not sure to understand your proposition, is it
> to generate setXXX and getXXX methods (i.e. accessor methods
> as specified in EJB 2.0) for each XXX CMP field ?
>
> François
> --
> ==================================================================
> Francois EXERTIER Evidian (Groupe Bull)
> 1, rue de Provence, BP 208, 38432 Echirolles cedex, FRANCE
> mailto:[EMAIL PROTECTED]
> http://www.evidian.com/jonas http://www.objectweb.org/jonas
> Tel: +33 (0)4 76 29 71 51 - Fax: +33 (0)4 76 29 77 30
> ==================================================================
>
>
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-users".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".
>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
