Semantics of peek(fqn) and peek(fqn, key)

[ben.wang]

Currently, we have different semantics for peek(fqn) and peek(fqn, key) that in the the later, we will go thru the interceptor chains (e.g., replication, lock, etc.) while the former doesn't.

Should peek(fqn) also goes the interceptor chain such that lock, cache loader, and passivation can be treated correctly?

[manik]

Yes, I would have thought they'd behave the same. Were they created for different purposes? Where are these 2 methods used?

[belaban]

Well, my idea was that peek() would for example *not* load an element from the loader, similar in semantics to exists(). It should also not acquire any locks, that's why.

[ben.wang]

Maybe we need to define it a bit more clearly. Since peek() also returns the object now, locking maybe be necessary. I did the peek(fqn, key) to avoid trigger any node visit event. :-) Maybe this can be lumped into Option argument.

Now, I use peek(fqn) in the PojoCache to avoid it going thru the EvictionInterceptor. This is a hack that I will get rid of in 2.0.

[manik]

If this is used internally (i.e., not a public API method - and I don't see why it should be public API) why not just use _get()?

[ben.wang]

That's the point. Ideally, I want to have a get that doesn't go thru a certain interceptor (e.g., eviction) or a put that skip some interceptor (e.g., eviction or replication). But key is I still need it to go thru LockInterceptor.

[manik]

Well, neither of the peek() methods offer this at the moment.

peek(Fqn, key) simply calls get(fqn, key, false) - the last false parameter just suppresses notifications to listeners but doesn't suppress any other interceptors.

peek(Fqn) just calls findInternal(fqn) - same thing as calling _get() with appropriate params?