Refactoring Purging

First a quick update for everyone reading this: I've done a first round
of the Authenticated refactoring, making the selection of the
SessionManager and SessionValidator completely dynamic based on element
configuration. There are no more Mixed element classes since they are
just the database elements with the memory-based session classes
configured in. Application code that uses rife/authenticated/mixed.xml
won't notice the difference.

But now for the real reason I'm writing this: While I was thinking about
what I want to use this newfound configuration for, I had an idea about
how to factor out the Purging stuff too.

What I want to do is put a caching layer on top of the user and session
data so I don't have to hit the database to fetch the data for a user
who's currently logged in. But I *do* want a database sitting under the
cache; whenever there's a cache miss the database should be consulted
and the cache should be populated.

So basically I want to wrap a caching facade object around the
underlying database-capable objects. And it would be great to allow a
stack of these facades, much in the same way we can stack child-trigger
elements if we want to.

Once that general mechanism is in place, purging is just another thing
that can be layered on top of a SessionManager and/or RememberManager.
In fact, the current implementations of PurgingSessionManager and
PurgingRememberManager barely need to change at all; the only difference
is how the system knows to instantiate them and what to wrap them
around. And the purging behavior could be layered on top of, say, my
caching wrapper.

I think the general principle is probably not that controversial. The
interesting question is, what does the configuration look like? And
that's where I'm less certain.

Spring actually has a reasonable syntax for configuring which beans are
wrapped in which others -- you define the underlying bean, then define
the wrapper bean and configure the underlying bean as a property of the
wrapping bean. But since RIFE doesn't have an equivalent configuration
mechanism for low-level objects, I think that might be a bit too
heavyweight of a change to introduce. On the other hand, if we're
willing to bite that bullet, it probably *is* the most flexible way to
go about this.

Instead, though, maybe something simpler is in order. Something like
this (using some of the new properties I've introduced in my
refactoring; hopefully it's easy enough to follow.) This is a definition
for an element that uses a purging wrapper around a caching wrapper
around a database session manager.

First, database.xml (minus the stuff not related to session managers,
for the sake of example):

<element extends="rife/authenticated/authenticated.xml">
    <property
name="sessionmanagerfactory_class">DatabaseSessionsFactory</property>
    <property name="datasource"></property>
    <property name="sessionmanager_wrap_prefix">db_</property>
</element>

This is just like a normal (post-refactoring) session manager
declaration: a factory class and the parameters it needs to instantiate
its objects. The new thing is the last property; the easiest way to
explain it is by proceeding to the next element, databasecaching.xml:

<element extends="rife/authenticated/database.xml">
    <property
name="db_sessionmanagerfactory_class">SessionManagerWrapperFactory</property>
    <property
name="db_sessionmanager_class">CachingSessionManagerWrapper</property>
    <property name="db_cache_size">1M</property>
    <property name="db_cache_expiration">LRU</property>
    <property name="db_sessionmanager_wrap_prefix">cached_</property>
</element>

Here all the properties are prefixed with the wrap prefix defined by the
element we're wrapping. This prevents namespace collisions. All the
classes involved will be able to take prefix arguments and will know to
strip off their prefixes when looking up their properties. With that in
mind, this looks similar to the initial element: we define a factory
class (in this case, one that knows how to produce wrapper classes; it
will pass the underlying database session manager to the wrapper's
constructor) and tell the factory what underlying class to make. That
underlying class has some properties. Then we define the next prefix in
case there's another element in the chain, which in this case is in
databasecachingpurging.xml:

<element extends="rife/authenticated/databasecaching.xml">
    <property
name="cached_sessionmanagerfactory_class">SessionManagerWrapperFactory</property>
    <property
name="cached_sessionmanager_class">PurgingSessionManagerWrapper</property>
    <property name="cached_purge_frequency">...</property>
    <property name="cached_sessionmanager_wrap_prefix">purged_</property>
</element>

Another wrapper as before, which also defines a prefix for the next link
in the chain. But this time there isn't one. The session manager setup
code will look for a "purged_sessionmanagerfactory_class" property on
the current element, not see one, and will return the
PurgingSessionManagerWrapper object to the caller.

I admit the notion of using prefixes is a little wacky; you really
*should* be able to use the same properties at each level so you don't
have to change your element's properties just to wrap a different
parent. But (as I just confirmed with Geert on IRC) the namespace of
element properties is flat, so you pretty much have to do something like
this to represent an arbitrary chain of parameterized objects.

As with my current round of refactoring, this new flexibility is
completely hidden from applications that just want to use the pre-canned
"databaseunpurged.xml" or whatever. They continue to extend those XML
files as before, blissfully unaware that stuff has gotten more dynamic
under the covers.

What do you guys think?

-Steve
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel