Paul,
> On Aug 26, 2008, at 7:41 PM, Markus KARG wrote:
>>> In relation to Travis's point about the server-side, i also think
>>> technologies like Ehcache are interesting, especially to avoid DB
>>> queries or say to help with fast look up of etag last-modified data
>>> (e.g. like memcached), so there may be something that could also be
>>> done with Jersey/Ehcache for conditional GET/PUT/DELETE.
>> The question is whether that is useful.
> Note that i am not referring to an HTTP cache. For *conditional*
> GET/PUT/DELETE the application determines the etag and last-modified
> date and the application returns a 304 Not Modified or the content for
> a GET or returns a 412 Precondition failed for a PUT/DELETE.
> Essentially the Ehcache can be used as an efficient hash table of key
> (uri) to etag/last-modified. A conditional GET will check the cache. A
> PUT/DELETE will modify/clear the cache. IIRC Rails does something
> using memcached.
>
> It is possible to do the same with SQUID?
SQUID, as every other HTTP/1.1 compliant cache, certainly correctly
handles *conditional* GET/PUT/DELETE and deals with it in the way you
described above. The JAX-RS resource will only get queried by SQUID,
when SQUID's decides that there is a real need (e. g. cached entity is
not fresh anymore etc.).
I understand that it is a heavy burden for the resource to find out the
entity's current ETag and LastModified date needed for the input of the
Request.evaluatePreconditions(). But: I think in reality most of the
JAX-RS entities will be retrieved from JPA. Most JPA implementation
already have a client sided cache in addition to the DBMS's server sided
cache.
So I asked "Is it worth that?" because I think that the performance gain
is not so high that one might expect, but it will be difficult to
guarantee that the additional Hash Table is updated in all places and
under all circumstances. So "Is it worth that?" is not a question about
performance gains, but about the relation between *real* performance
gain on one side compared to efforts taken to guarantee correct
behaviour in all circumstances on the other side.
Why do I think that it is complex to do? Because: Only the database
knows the actual ETag and LastModified -- there can be other
applications besides JAX-RS accessing the same entities in a parallel
manner. So JAX-RS's Hash Table must be configurable (somehow I must tell
it when it is save to not talk to the database). Since JAX-RS is not a
database access technology already, this is an additional feature to
learn, which brings complexity, which brings efforts and risks.
So again, do we all really think that it is worth adding another cache
into JAX-RS in addition to a simple SQUID in front of JAX-RS and JPA's
and DBMS's cache behind JAX-RS? Is that gap so large that the risk is
worth it? If we can proof this, then I say: Yes, let's do that. But just
from the bottom of my belly I would say: Nay, too risky.
Regards
Markus
--
http://www.xing.com/go/invita/58469