Hi,

calling methods is something else as calling persistency. Be aware that this is a JSF problem and avoid putting complex calls in the bean accessors.

Leo

What Leo has said is a common issue that many people find themselves running into during JSF development. It is extremely important that you are aware of the JSF lifecycle and the impact it will have on the code you write.

Every EL expression (well, almost every EL expression) you have on a xhtml page can be resolved n+1 times. The value of n depends on a whole bunch of factors. But, the real issue here is that it is very rare that an EL expression will only get resolved once in page lifecycle (Restore model through to render response). In fact it is highly likely that it will be resolved no less then 4 times per cycle.

So, with that in mind you now need to write your code in such a way that getters and method binding expressions used in rendered attributes do nothing (or as close to nothing as possible) except return a value.

There are many ways to achieve this. My personal favourite is to collect all the data I need up front and set all the necessary vars and then only modify these variables when an action or actionListener is executed. But, how you achieve good JSF code is going to be based largely on your app.

I would HIGHLY recommend reading Dan Allen's article as it will give you a better understanding of what's going on.

Hi,

... and additionally, look at the BypassInterceptors annotation, which does excectly what it states. A simple trick is to add a getInstance() method which provides access to the managed bean and put a single annotation on that method. saves you a lot of time/keystrokes:

private WhateverBean yourBean; 

@BypassInterceptors
public WhateverBean getInstance(){
return yourBean;
}

I normally prefer the factory approach or also the one from tim. In simple cases the event scope is matching this perfectly. Sometimes you need what i call a subevent scope because the value will change its state during the lifecycle. Like from new to persisted.

The factory in the eventscope does the preparation of an object (eventcontext) for you. Which is what tim is doing on himself. The little disadvantage can be that you have alot of eventvars flying around in this context. But this level i did not reach yet so that this would anoy me.

I even go that far that i create factories for the rulebased permissions. This avoids calling drools 1000x times to check if a textfield has to be rendered in editmode or displaymode.

Martin

Thanks Leo for adding the @BypassInterceptors info....completely forgot to mention that :S

Tauseef, I don't know exactly how to solve your issue, but maybe caching is the answer. I don't have experience in caching the particular entities/security queries you are dealing with but, it should be possible.

Hopefully someone with a bit more experience in the area can help. But, in the meantime maybe investigating caching strategies for the PersistentPermissionResolver may yield some useful information.

Hi Tauseef,

The JPA persmision resolver makes a query to the database to lookup permissions. If - as you state - you have millions of records, it will a long time to look up a specific value, try indexing your table, (although I think that will solve only a small part) or use another resolver. The drools one is very efficient, but difficult to maintain unless you use a load permissions as beans in the working memory and check them again the permissions (it is REALLY fast !).

Another thing which comes to my mind it that possibly your permissions are a bit too fine-grained, because I can't imagine you need millions of different permissions in your database. maye you could simplify that and make a more generic permission scheme.

Leo