"jason.greene(a)jboss.com" wrote :
| but if the performance sucks as bad as this does, no one will use it.
|
Didn't you use this with PojoCache, but never noticed the bad performance? ;-)
"jason.greene(a)jboss.com" wrote :
| In general we should avoid expanding our usage of this until we know that the design is even fixable.
|
If Google can search a googol of entries in a split sec,
I don't see why we couldn't do the same for a handful of beans and aspects.
Kabir, what's the current search/matching mechanism?
Can it be made plugable?
Or how much would it take to improve that?
Idea of Lucene or Hadoop (on a single cpu) comes to my mind ... :-)
Or basically any decent BTrees impl should do.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230686#4230686
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230686
anonymous wrote :
| How are task lists impacted when we are using swimlane candidate-groups which both a user and a group of users [organisation] can belong?
|
I was wondering about "candidate-group" and "candidate-user" as well.
Not sure if that fits your question, but I'll throw it in anyway:
- Should those two statement be mutual exclusive an a single task activity?
- Why a "candidate-user" in the first place?
- Does a set of "candidate-users" form an artificial "candidate-group"?
- How does re-assignment fit into the picture? Who is privileged to re-assign a task? Does the user need to be in one of the "candidate-groups"?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230684#4230684
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230684