You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Tomi NA <he...@gmail.com> on 2006/11/15 09:05:26 UTC
cayenne in a (rich) client/server setup
I'm developing a rich client application using cayenne as the ORM.
So far I've used cayenne in web applications only, and as far as I can
tell, it's the dominant use case.
Seeing how rich clients arround a db server are a very different story
(cayenne running in different JVMs on different machines, rather than
in one JVM on the server), is there anything I should be paying
special attention to, especially along the lines of caching data and
locking mechanisms?
TIA,
t.n.a.
Re: cayenne in a (rich) client/server setup
Posted by Tomi NA <he...@gmail.com>.
2006/11/15, Andrus Adamchik <an...@objectstyle.org>:
> Also take a look at nested DataContexts. In desktop apps they are
> much more useful than in web apps, e.g. for things like nested
> dialogs, where you need to save or cancel dialog input without saving
> to the database.
I just took a look at nested DataContexts and think I'll add them to
the "improvements" TODO section. For now, I'm working with one context
for the whole application.
I'll seriously consider the possibility of using contexts within my
main context and see what I come up with.
For now, thanks everyone: I'm a bit more at peace. It was some time
since I tackled concurrent db access issues, but it's all coming back
to me.
t.n.a.
Re: cayenne in a (rich) client/server setup
Posted by Andrus Adamchik <an...@objectstyle.org>.
Also take a look at nested DataContexts. In desktop apps they are
much more useful than in web apps, e.g. for things like nested
dialogs, where you need to save or cancel dialog input without saving
to the database.
Andrus
On Nov 15, 2006, at 8:53 AM, Michael Gentry wrote:
> Back in the old days, when I used to do NeXTstep/EOF development, this
> was pretty much how we did it. EOF (Cayenne) was used to access the
> DB and it worked well. As far as things to pay attention to ... I'd
> use optimistic locking (which I'd recommend for a web-based
> application, too) and refresh data you think needs to be refreshed.
> Refreshing data is really an application/workflow specific detail, so
> it is hard to generalize. Some things are obvious, like you can cache
> the State and Zip Code tables, for example. Other things you'll have
> to evaluate depending on your situation. It hardly ever hurts to
> refresh data from common queries, unless the query is really slow.
>
> Not sure if that helped ...
>
> /dev/mrg
>
>
> On 11/15/06, Tomi NA <he...@gmail.com> wrote:
>> I'm developing a rich client application using cayenne as the ORM.
>> So far I've used cayenne in web applications only, and as far as I
>> can
>> tell, it's the dominant use case.
>> Seeing how rich clients arround a db server are a very different
>> story
>> (cayenne running in different JVMs on different machines, rather than
>> in one JVM on the server), is there anything I should be paying
>> special attention to, especially along the lines of caching data and
>> locking mechanisms?
>>
>> TIA,
>> t.n.a.
>>
>
Re: cayenne in a (rich) client/server setup
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 15, 2006, at 2:14 PM, Michael Gentry wrote:
> Named queries and the getObject* will/can use the object cache.
Only if cache policy is set on named queries.
> Normal queries should refresh.
Only if cache policy is not set.
So there is no difference between the queries created in the API and
mapped in the Modeler as far as caching is concerned:
http://cwiki.apache.org/CAYDOC/caching-query-results.html
DataContext.performQuery(String,Map,boolean) mentioned in the docs
was a way to refresh the cache that should be considered obsolete now
(I think).
> I'm not totally clear on the object cache workings. I know I've had
> things live for weeks in it before (actually helped us out with a
> production problem -- we could get the old data and print it so we
> didn't lose it, but I'd argue that was a bad design decision on my
> part).
Till 3.0 query cache didn't have expiration date. Now it does.
> There was talk about adding new cache options to 3.0, but I
> don't believe you are using that branch? (I think Andrus may have
> added LRU functionality or similar?)
Yes, and a bit more - an ability to define cache expiration
algorithms via a factory:
http://www.mail-archive.com/cayenne-user@incubator.apache.org/
msg01196.html
Andrus
Re: Re: cayenne in a (rich) client/server setup
Posted by Tomi NA <he...@gmail.com>.
2006/11/15, Michael Gentry <bl...@gmail.com>:
> Named queries and the getObject* will/can use the object cache.
> Normal queries should refresh.
getObject* can't be configured to go to the database?
> part). There was talk about adding new cache options to 3.0, but I
> don't believe you are using that branch? (I think Andrus may have
> added LRU functionality or similar?)
You're right, I'm not. This project is based on 1.2 - I'm probably
going to port it to 2.0.x after the first installation, but it
probably doesn't make a difference in the context were talking about
now.
The bigger bang might be switching to ROP altogether, but I have to
think about that one very carefully for reasons entirely disjoint from
cayenne itself.
As far as LRU's concerned, I don't really see how it fits into the
entire picture: isn't it just a way of deciding what remains in a
limited size cache, and what doesn't? It certainly allows performance
tuning (memory vs. CPU wise), but has little bearing on questions of
keeping in-memory data up to date...
t.n.a.
Re: Re: cayenne in a (rich) client/server setup
Posted by Michael Gentry <bl...@gmail.com>.
Named queries and the getObject* will/can use the object cache.
Normal queries should refresh.
I'm not totally clear on the object cache workings. I know I've had
things live for weeks in it before (actually helped us out with a
production problem -- we could get the old data and print it so we
didn't lose it, but I'd argue that was a bad design decision on my
part). There was talk about adding new cache options to 3.0, but I
don't believe you are using that branch? (I think Andrus may have
added LRU functionality or similar?)
/dev/mrg
On 11/15/06, Tomi NA <he...@gmail.com> wrote:
> 2006/11/15, Michael Gentry <bl...@gmail.com>:
>
> > DB and it worked well. As far as things to pay attention to ... I'd
> > use optimistic locking (which I'd recommend for a web-based
> > application, too) and refresh data you think needs to be refreshed.
> > Refreshing data is really an application/workflow specific detail, so
> > it is hard to generalize. Some things are obvious, like you can cache
> > the State and Zip Code tables, for example. Other things you'll have
> > to evaluate depending on your situation. It hardly ever hurts to
> > refresh data from common queries, unless the query is really slow.
>
> As far as refresh is concerned...
> Cayenne looks to the database for every query by default, correct? If
> an object changes after performQuery or getObjectByID returns, how
> would I go about refreshing the cache?
> Simply repeat getObjectByID or performQuery?
> So far I've taken the paranoid approach so everything comes straight
> from the database (i.e., I haven't paid any attention to the cache):
> I'll look into the possibilities of caching some tables. which
> shouldn't change.
>
> How does the "max. number of objects" fit into the story? What happens
> if I run a query which returns more then "max. number of objects"
> objects (I've tried it, but can't explain the result)?
>
> t.n.a.
>
Re: cayenne in a (rich) client/server setup
Posted by Tomi NA <he...@gmail.com>.
2006/11/15, Michael Gentry <bl...@gmail.com>:
> DB and it worked well. As far as things to pay attention to ... I'd
> use optimistic locking (which I'd recommend for a web-based
> application, too) and refresh data you think needs to be refreshed.
> Refreshing data is really an application/workflow specific detail, so
> it is hard to generalize. Some things are obvious, like you can cache
> the State and Zip Code tables, for example. Other things you'll have
> to evaluate depending on your situation. It hardly ever hurts to
> refresh data from common queries, unless the query is really slow.
As far as refresh is concerned...
Cayenne looks to the database for every query by default, correct? If
an object changes after performQuery or getObjectByID returns, how
would I go about refreshing the cache?
Simply repeat getObjectByID or performQuery?
So far I've taken the paranoid approach so everything comes straight
from the database (i.e., I haven't paid any attention to the cache):
I'll look into the possibilities of caching some tables. which
shouldn't change.
How does the "max. number of objects" fit into the story? What happens
if I run a query which returns more then "max. number of objects"
objects (I've tried it, but can't explain the result)?
t.n.a.
Re: cayenne in a (rich) client/server setup
Posted by Michael Gentry <bl...@gmail.com>.
Back in the old days, when I used to do NeXTstep/EOF development, this
was pretty much how we did it. EOF (Cayenne) was used to access the
DB and it worked well. As far as things to pay attention to ... I'd
use optimistic locking (which I'd recommend for a web-based
application, too) and refresh data you think needs to be refreshed.
Refreshing data is really an application/workflow specific detail, so
it is hard to generalize. Some things are obvious, like you can cache
the State and Zip Code tables, for example. Other things you'll have
to evaluate depending on your situation. It hardly ever hurts to
refresh data from common queries, unless the query is really slow.
Not sure if that helped ...
/dev/mrg
On 11/15/06, Tomi NA <he...@gmail.com> wrote:
> I'm developing a rich client application using cayenne as the ORM.
> So far I've used cayenne in web applications only, and as far as I can
> tell, it's the dominant use case.
> Seeing how rich clients arround a db server are a very different story
> (cayenne running in different JVMs on different machines, rather than
> in one JVM on the server), is there anything I should be paying
> special attention to, especially along the lines of caching data and
> locking mechanisms?
>
> TIA,
> t.n.a.
>