Christian Haul wrote:
Woohoo! "If you build it they will come..." I was beginning to despair that I was the only one who found this even remotely useful (ok, there are a few others).
:-)
The more useful way of course would be to do this through JMS. The docs already suggest this.
Yes, that is my favorite paradigm for caching database-driven stuff. I've had for some time the beginnings of a JMS block on my hdd. I can't remember the state of it. IIRC I have it connecting to a remote/local JMS server depending on config and capable of basic receiving of events. I don't think I ever worked in durable subscriptions which would be a must.
Yes, durable subscriptions would be nice. I've been too lazy to set up OpenJMS to do it though :-P But I think it's not very difficult.
I guess, a JMS block would basically consist of a component that receives events like JMSEventListener contained in the tar.gz? What else would be nice to have, an action / a component sending notifications?
Now, I took some time to build upon what's already there and created an additional example that provides triggers for HSQLDB for automatic invalidation, either through HTTP or through JMS. Since most (all?) commercial DBMSs support Java stored procedures or functions (well, any language would do for the HTTP method), it should be simple to extend this to other DBMSs.
Ok, I'll need to look at this. I didn't think most DBMSs supported Java stored procs. I've just started working on this in Oracle 9i. Did this some time ago with 8i but things have changed slightly. I had no idea HSQL supported it - is that what you're saying? I haven't followed real
I believe the big commercial DBMSs support "java in the database". Well, I guess MS SQL doesn't ;-D Oracle, Sybase, DB2, and INFORMIX do. Anyway, all should support extensions in some language like C, C++, VBScript (shudder). Open source DBMS written in Java (like HSQLDB, McKoi) are fine, those written in another language should be at least extendable as long as they support triggers. (Can't reach postgres.org ATM)
recently but MySql is working on stored procs but I don't think Java is in the cards there. Still, a simple wrapper would probably work fine.
However, to compile the updated block, certain java.naming and
java.jms classes need to be present. Available from sun or obtainable
together with a complete JMS implementation from http://OpenJMS.sf.net IIUC the jms and jndi jars are redistributable. We could add them to
our CVS (?)
I didn't think they were redistributable but have no real idea. I'd love to not have the block depend on JMS since it's not strictly needed. Could we have a JMS block (as I mentioned above) which then has some eventcache-specific code?
If you go to http://java.sun.com/products/jms/docs.html and select to download API docs & JARS, you will be presented a licence page. Scroll down to the middle:
JAVATM INTERFACE CLASSES JAVA MESSAGE SERVICE (JMS), VERSION 1.1 SUPPLEMENTAL LICENSE TERMS
[...]
2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to Section 3 (Java Technology Restrictions), Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary form only, provided that you [...]
IANAL so I have no clue if we are fulfulling the provisions.
Another nice feature would be to make the SQLTransformer cachable with
the same technique.
Unico came up with a solution for this that I like. It's not documented and no sample yet, but see the EventCacheGenerator in the block. IIRC it's a pretty classic Decorator that just adds/replaces the caching behavior of any Generator and delegates all other functions to it without recoding it. To do the same for transformations wouldn't be a big deal. (or was that what you were already referring to?)
I was thinking along those lines but have discarded that because I'm afraid that really a proxy is needed that would need to expose the very same interfaces as the proxied component, like setup & friends.
Haven't investigated which interfaces would need to be considered, though.
For this it would be great if the eventcache block could be moved into core, at least the EventAware interface.
I'd be fine with this and even at one point thought of proposing it. Two
Great!
I'll check it out soon. Unfortunately I'm working on installing doors to keep my daughter out of my office. http://images.myaeros.com/matt/5.jpg
Sweet!
I'll package up the jms block I had going if that sounds worthwhile.
Absolutely.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
