The current implementation doesn't limit anything. It simply
performs an unnecessary new ObjectStore(DataRowStore) construction,
which, in the case of providing your own ObjectStore, can be ignored
and will be garbaged-collected.
The only potentially-expensive or significant operation in this is
EventManager.getDefaultManager().addNonBlockingListener(
this,
"snapshotsChanged",
SnapshotEvent.class,
dataRowCache.getSnapshotEventSubject());
I'm not entirely certain what the side effects would be of leaving
this event registered for an unused ObjectStore, but I guess the
person implementing their own ObjectStore would be responsible to
clean it up, if needed.
On 9/16/05, Kevin Menard <kmenar..ervprise.com> wrote:
> Mike Kienenberger wrote:
> > Yeah, it's the " but still..." that could make it harder.
>
> Hmm . . . you guys have me drawn here. Part of me says don't limit the
> usefulness for the user, but the other part says make it as easy as
> possible. Couldn't we use the rather standard interface, abstract class
> interaction?
>
> So, basically there would be an interface that's general, like Andrus's,
> but a default abstract class that other factories could inherit from,
> and this class would provide simple wrappers. So, that extra line of
> code that Andrus mentioned and that does seem hairy could really be
> hidden from the user. Of course in the user's DataContextFactory
> implementation, he'd have to know which super method to call, but I
> think an aptly named method here could accomplish what is needed without
> introducing the user to shared caches and such . . .
>
> --
> Kevin
>
This archive was generated by hypermail 2.0.0 : Fri Sep 16 2005 - 09:04:18 EDT