François,
thank you. There is no hurry. We have to deliver in May, so this is not a question of
days.
Markus
> Thanks for the explanations. I have now a better understanding
> of what you are proposing and will think about it (unfortunately
> I've got meetings today and tomorow morning ...).
>
> Just quickly some first feelings:
> For "server caching", you can wait EJB 2.0 JOnAS impl,
> or modify GenIC to generate setXXX and getXXX methods,
> this is not forbidden by EJB 1.1 ...
>
> For client caching, I think modifying the RMI stubs
> is not so simple ...
>
> Regards,
>
> François
>
> [EMAIL PROTECTED] wrote:
>
> > 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.
