commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vandahl ...@apache.org>
Subject Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?
Date Mon, 26 May 2014 18:55:19 GMT
On 25.05.14 17:18, Romain Manni-Bucau wrote:
> Extras is a set of useful basic classes for JCache usage. OpenJPA is JCache
> support for L2 cache in openjpa.
> 
> The goal is to make what we propose with jcache module as usable as
> possible and avoid glue code as much as possible in application code.

>From what I see, caching is something very generic and there is a
plethora of strategies that you can use to cache you data. JCS for
example is the caching layer for DB-Torque where auxiliaries like
JDBCDiskCache would not make sense. Nevertheless they may be used in a
different environment, e. g. when the calculation of the data to be
cached takes a lot of time.

Caching on the level of a request filter only works for simple web
applications. Mostly, the lifetimes of page fragments are very different
so that caching the complete request is not an option.

I'm not sure that such "application examples" or templates should be in
the scope of a project like this. I'm not aware of modules with this
focus in other projects of Commons, but I may be wrong. What do others
think?

> I was not that happy to do so but it made default usage really easier and
> opened several possibilities (L2 cache wouldn't have been seriousy possible
> otherwise since often entities are not serializable for instance).

Well, now, then how to handle the case in the current code when a disk
cache needs the value to be serializable and it isn't? Throw an
exception? Log something? What if fields of objects are not
serializable? With the declared interface, FindBugs helps me to track
down those problems. Without the declaration, you may find the problem
only when you are in production. I hope I can get my concerns across.
I like code that helps the developer avoiding errors, that's the whole
point of this discussion.

> We can create a branch from trunk (to keep code) and go back to a revision
> which is ok for you if you want to discuss commits.

Isn't this what "Community over Code" is supposed to mean? Peer review,
learn from each other, discuss the better concept?

Bye, Thomas.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message