> also make caching an inherent concept (are you ever really going to
use PD without caching results?)
Depends what you mean by this. For reasonable meanings (and I always
assume, on the basis of good experience, that you're going for
reasonable, Eric), that sounds good.
Historically, I did get some mileage out of being able to apply
different caching policies at different layers, making use of out of
band knowledge about the refresh cycles of particular data sources,
etc. I can't cite recent experience, but I do imagine that if I was
doing this sort of thing more often I'd have those experiences to cite.
Certainly I'll cache at at least one level in all PD configurations in
practice, but I don't necessarily want every DAO individually cached.
In the config I'm working on today, I have caching set up relatively
high in the tree (but not at the top -- that attribute swapping
implementation is cute...), and then I'm just not worrying about caching
around each individual DAO.
Anyway, I agree in concept with making person directory configuration
easier and the APIs more friendly, and making the caching defaults /
configuration easier. And I hope to be able to be involved in those
improvements in practice.
Andrew
PS: I mean cute in a good way, to be clear.
...
On 8/10/11 6:08 PM, Eric Dalquist wrote:
+1
I've thought about this often and just never had the time. We use a
lot of data sources at madison and it would really help login times a
lot if all those queries could be shuffled off into an ExecutorService.
On 8/10/11 4:58 PM, Andrew Petro wrote:
In the course of assisting with a uPortal implementation, I've been
re-familiarizing with the person-directory API and implementation.
In looking over the MergingPersonAttributeDaoImpl, I started
wondering: would there often be much advantage in this code invoking
the child DAOs in parallel rather than serially?
It's mostly an idle thought -- I don't have an immediate need for a
parallelized implementation on this project and I'm not proposing to
write this code -- but it seemed an interesting enough idea -- and
potentially one right in the smack of the critical path for a
successful login and render -- to be worth raising, see if anyone's
done this, or sees value in it.
Andrew
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
