[JIRA-Opensymphony] Commented: (CACHE-50) Allow third party code to send event notifications

The following comment has been added to this issue:

     Author: Sheldon Hearn
    Created: Wed, 6 Aug 2003 12:36 PM
       Body:
> I'm a bit unclear of your scenario, could you give me an example of
> what you mean by "group names are constructed in a way that identifies
> the entities from which data was used in cache entries"?

Sure.  Let's say I have a Category called "Sport" (with a unique Id of
5) and it parents a variable number of Events.  Let's say that, right
now, it happens to contain two Events, "Tennis" and "Boxing" (with
unique Ids of 42 and 66 respectively).

Then I do this:

<%
String groups = CacheUtil.getGroupNames(catSport) +
    CacheUtil.getGroupNames(eveFormula1) +
    CacheUtil.getGroupNames(eveTennis); // returns "cat5,eve42,eve66";

%>
<cache:cache groups="<%= groups %>" key="...">
...

As long as my Entity Beans have access to CacheUtil, they can construct
group names that identify themselves and use those group names to
broadcast flush events to the caching cluster.  In this way, changes to
entity beans automatically flush any cache entries that apply to them.

> Also, the sendNotification() method is *supposed* to be protected -
> it is there to abstract the details of sending a message across the
> cluster away from the AbstractBroadcastingListener. It wasn't designed
> to be called directly, rather it gets called as the result of a cache
> event.

Don't you love the way your software always gets used in ways you never
imagined?  We're really impressed with OSCache's flexibility.

> The clustering support is peer-to-peer, caches communicate with each
> other each time something gets flushed. It seems that what you really
> are after is a way to flush the caches 'externally' from the EJB tier,
> even though a cache does not live there?

Yes, that's exactly what I'm after.  It works very well, actually.
Previously, entities would talk to a JSP page via HTTP, and that JSP
page would call flushGroup().  But the multicast notifications are MUCH
faster. :-)

> I've made the ClusterNotification constants public which should solve
> your package dependency, but I've left the sendNotification() as
> protected since I'm not convinced that should be exposed (however you
> can still override it and make it public if you so choose).

Sure, but my overrider still has to be in the same package, which causes
problems (see below).

> In a post 2.0 build I'll try to come up with a cleaner way to allow
> external broadcasting.

Cool.  At the end of the day, that's all I need.  How I do it isn't that
interesting to me.  So if a future version of OSCache has a way to do
this, I'll use that instead of the uncomfortable work-around I'm using
now. :-)

Alternatively, if you decide there's no harm in promoting
sendNotification(), I'll be happy with that too.

> (Oh yeah one other small thing - you shouldn't have needed to alter
> oscache.jar at all, you should be able have a duplicate package name
> coexisting outside the jar file without problems. I do this often when
> I need to override/workaround a problem in a 3rd party library).

I don't think that's true in this scenario with JBoss, because if the
two classes are loaded with different classloaders, you get an illegal
access violation.  Since EJB jars and lib jars are loaded by separate
classloaders, I'm pretty sure the problem applies here.

---------------------------------------------------------------------
View the issue:

  http://jira.opensymphony.com/secure/ViewIssue.jspa?key=CACHE-50


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CACHE-50
    Summary: Allow third party code to send event notifications
       Type: Improvement

     Status: Assigned
   Priority: Minor

    Project: OSCache
 Components: 
             Listeners
   Versions:
             2.0 beta 2

   Assignee: Chris Miller
   Reporter: Sheldon Hearn

    Created: Wed, 6 Aug 2003 8:47 AM
    Updated: Wed, 6 Aug 2003 8:47 AM
Environment: OSCache used in JSP pages served by Tomcat.
JBoss providing data that we want to cache.

Description:
We're using OSCache to reduce expensive round-tripping between web containers and the EJB container.

We use groups to implement fine-grained cache control, where group names are constructed in a way that identifies the entities from which data was used in cache entries.

When entities change, the entities (running in the EJB container) fire cache flush notifications with JavaGroupsBroadcastingListener.sendNotification().

In this way, all cache entries associated with a changed entity are flushed.  It works wonderfully, and OSCache rocks hard, fast and furious.

The problems are:

1) AbstractBroadcastingListener and descendents declare sendNotification() protected, and

2) ClusterNotification's FLUSH_KEY, FLUSH_GROUP, FLUSH_PATTERN and FLUSH_CACHE constants are package-protected.

This means that we have to graft our own wrapper class into the com.opensymphony.oscache.plugins.clustersupport package and reroll oscache.jar.

Please consider promoting these overly protected members to public.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.opensymphony.com/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01