Re: Project Wonder: SharedEditingContexts
Re: Project Wonder: SharedEditingContexts
- Subject: Re: Project Wonder: SharedEditingContexts
- From: Lachlan Deck <email@hidden>
- Date: Mon, 15 Sep 2008 13:10:02 +1000
On 9/14/08 9:27 PM, "Mike Schrag" <email@hidden> wrote:
Does Project Wonder also have a replacement for
EOSharedEditingContext??
Project Wonder's replacement is "don't use it" ... So no.
Err .. no -- come on, be fair -- this is not true. It's just that most
people don't use it == scared of it == don't use it because of
misinformation.
On 15/09/2008, at 12:44 PM, Dov Rosenberg wrote:
Are there any issues if the WO version is used?
No. None.
I have, however, subclassed it recently to extend its core
functionality. i.e., mine (which I'm happy to contribute to Wonder)
enables it be treated like a regular ec -- so you don't have to think
about bind* and refreshing etc -- and as such creates a unique key
from an EOFetchSpecifcation which can be matched again the next time
the same query is performed.
As such, the fetch results themselves are cached automatically and I'm
using the timestampLag to determine when to return the same results or
when to refresh the query.
We have a JSP tag library
that we created that is mostly readonly. We used the shared editing
context
to improve the overall performance of our tag library quite a bit over
regular EO’s. Does Wonder have a better strategy for caching
frequently
fetched things that are readonly? It took us quite a bit of tweaking
our
code to get the shared editing context working reliably over the
years but
it is working pretty well at this point. We moved over to Wonder to
replace
the older JMS based change notification system with the newer jgroups
version (hopefully that should be working now – thanks everyone)
Our taglibrary can be pretty heavily trafficed so we don’t want to
overwhelm
the db server with jillions of queries. Any thoughts are appreciated.
Dov Rosenberg
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden