[Design of JBossCache] - Re: CacheListener callbacks for block/unblock
by jason.greene@jboss.com
"bstansberry(a)jboss.com" wrote : Yeah, I agree it's not normal. My only concern here is you can't really add it later. CacheListener is an interface people actually implement themselves, so "an added method isn't an API change" thinking breaks down.
|
Right instead you have to introduce a new interface (ExtendedCacheListner or BlockCacheListener).
One thing I was toying with in POJO Cache, that I might introduce at a later date is an annotation driven listener, which is more flexible and extensible:
| @AttachNotificationListener
| @DetachNotificationListener
| @ListModifyNotificationListener
| public myMethod(Notification notification)
| {
| ....
| }
|
or they could do (both would work)
| @AttachNotificationListener
| public void myMethod(AttachNotification notification)
| {
| ....
| }
|
| @DetachNotificationListener
| public void myMethod(DetachNotification notification)
| {
| ....
| }
|
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052673#4052673
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052673
18 years, 10 months
[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine
by jason.greene@jboss.com
A one shot option that is not associated with a method is error prone and verbose for calling code.
Consider this code
| cache.getOptions().setForceWriteLock(true);
| String atomicUserCounter = cache.get("/user/123", "counter");
|
Later someone assumes this is a persisting option and updates it
| cache.getOptions().setForceWriteLock(true);
| String atomicUserCounter = cache.get("/user/123", "counter");
| String atomicGroupCounter = cache.get("/group/456", "counter");
|
The fix is overly verbose:
| cache.getOptions().setForceWriteLock(true);
| String atomicUserCounter = cache.get("/user/123", "counter");
| cache.getOptions().setForceWriteLock(true);
| String atomicGroupCounter = cache.get("/group/456", "counter");
|
That said persistent options could lead to problems as well.
An overloaded parameter is neither error prone, nor overly verbose, and is intuitive:
| Options options = new Options();
| options.setForceWriteLock(true);
| String atomicUserCounter = cache.get("/user/123", "counter", options);
| String atomicGroupCounter = cache.get("/group/456", "counter", options);
| String regularReadValue = cache.get("/foo", "foo");
|
You could even offer constant options (via an immutable extension):
| String atomicUserCounter = cache.get("/user/123", "counter", Options.FORCE_WRITE_LOCK);
| String atomicGroupCounter = cache.get("/group/456", "counter", Options.FORCE_WRITE_LOCK);
| String regularReadValue = cache.get("/foo", "foo");
|
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052667#4052667
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052667
18 years, 10 months
[Design of JBossCache] - Re: CacheListener callbacks for block/unblock
by bstansberry@jboss.com
Yeah, I agree it's not normal. My only concern here is you can't really add it later. CacheListener is an interface people actually implement themselves, so "an added method isn't an API change" thinking breaks down.
I need to think quite a bit about whether/how I could use such callbacks to get a benefit beyond what Vladimir's done. My "shower thinking" a couple days ago had some ideas, but they don't seem so coherent as I've thought about it today.
If it turns out there is a good use for them, I could always of course have the AS do tricks (e.g. a CacheImpl subclass) to get notifications. Ugly, but not the end of the world.
In general, this thinking arises out of a concern that the multiplexer is going to lead to more frequent block calls for the JBC instances in the AS. The caches all share a channel, so one app doing a state transfer on a redeploy will cause a block on all caches. So, I'm noodling about strategies to minimize the impact of that.
[Semi-OT] One thing I'll have to have a look at is whether the blocking stuff Vladimir did discriminates between txs that have done a write and those that haven't. Unless cache is SERIALIZABLE, there's no reason to prevent reads or to rollback txs that have only done reads. Similar thinking applies to OPTIMISTIC -- since the tx workspace is not included in any state transfer, there is no reason to worry about any optimistic calls except the prepare.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052664#4052664
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052664
18 years, 10 months
[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss
by bill.burke@jboss.com
I've been thinking about this a bit the last day. Here's the advantages, IMO, of the new deployer I'm proposing:
* Easier for newbie to get start. One last thing they have to worry about.
* Easier for development
* Less configuration
* Doesn't impair other jBPM deployment options
* gets in line with how other JEMS projects deploy into JBsos
Disadvantages:
* Not portable to other application servers. (Until we get JBoss Embedded going).
* I don't think this will work well with class versioning unless we add metadata to the .par (like a version number)
My questsions are:
* How often is versioning used?
* How many versions are live at one time? How many versions do applications usually have in play?
One last thing:
* Maybe with this new deployer, versioning should be turned off by default?
* Should a piece of metadata be added to the deployment to say whether or not it should be versioned or just overwrite the old deployment?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052653#4052653
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052653
18 years, 10 months