Re: Assign workflow steps to groups/roles

Ah, one point I should have made clear is that this threadlocal is per 
request, so it's not used across different requests, hence all it does 
is ensure that within one request, only one query happens to see if a 
user belongs in a particular group or not.

On Tuesday, May 6, 2003, at 05:35 PM, jason vorhees wrote:

> Hani,
> Why would you use TreadLocal for your cache?
>
> Since each thread would have its own version of the
> cache it would seem that you would have the potential
> to have inconsistent caches.
>
> also how do you remove a user who is removed from a
> group from your various ThreadLocal caches?
>
> --- Hani Suleiman <[email protected]> wrote:
>> I solve this by using my own caching group check
>> function, using
>> ThreadLocals. Basically what happens is that every
>> time there's a group
>> check (OSUserGroupFunction I think, too lazy to look
>> up the actual
>> classname), I use my own group function, which
>> pretty much does what
>> the standard group function does, except that it
>> uses a threadlocal
>> context which stores both cache hits and misses, so
>> that the user is
>> only ever checked against a group once, with the
>> rest of the checks
>> being very fast cache hits. Unfortunately you still
>> end up potentially
>> looping over hundreds of steps, but the cost per
>> iteration is very
>> minimal, so the performance becomes a lot more
>> decent.
>>
>> Another option is to subclass your chosen
>> AbstractWorkflow
>> implementation and add a method which uses jdbc to
>> constrain the number
>> of steps returned to somehting that matches your
>> group requirement,
>> rather than doing it at the appserver level.
>>
>> On Monday, May 5, 2003, at 11:36 AM, Philipp Hug
>> wrote:
>>
>>> Does anyone use roles/groups in his workflows? How
>> did you implement
>>> them?
>>> The example workflow assigns workflow steps to
>> owner "null" and then
>>> uses
>>> permissions
>>> to see if a uses is allowed to see/change this
>> workflow.
>>> The problem with this implementation is, that it
>> doesn't perform very
>>> well,
>>> because you might need to loop over hundereds of
>> steps assigned to
>>> "null".
>>> How about adding a owner group field to Step? But
>> now, if someone is
>>> in a
>>> bunch
>>> of groups you have to do a lot of queries.
>>> Any ideas?
>>>
>>> Philipp
>>>
>>>
>>>
>>>
>>
> -------------------------------------------------------
>>> This sf.net email is sponsored by:ThinkGeek
>>> Welcome to geek heaven.
>>> http://thinkgeek.com/sf
>>> _______________________________________________
>>> Opensymphony-developers mailing list
>>> [email protected]
>>>
>>
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>>>
>>
>>
>>
>>
> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Opensymphony-developers mailing list
>> [email protected]
>>
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise 
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com