我给分，难道不要么？
已经通过acegi登陆认证的用户访问系统受保护资源时，acegi验证访问权限是通过SecurityContextHolder来获取的，不是从userCache中取到的。
如果修改用户密码或访问权限之后调用userCache的
userCache.removeUserFromCache(user.getUserCode());//user是用户bean对象
userCache.putUserInCache(userDetail);//userDetail是acegi的Principal
但是这个操作不对SecurityContextHolder起作用，因为从SecurityContextHolder读取到的信息没有变，这样的话就acegi的认证不能与数据库同步。
我的理解对否？

------解决方案--------------------
Acegi最基础的对象是SecurityContextHolder。在这里存储了当前应用的安全上下文（security context），包括正在使用应用程序的principal的详细信息。SecurityContextHolder默认使用ThreadLocal来存储这些详细信息，这意味着即便安全上下文（security context）没有被作为一个参数显式传入，它仍然是可用的。如果在当前principal的请求处理后清理线程,那么用这种方式使用 ThreadLocal是非常安全的。当然， Acegi Security自动为你处理这些，所以你无需担心。

有些应用程序由于使用线程的方式而并不是完全适用ThreadLocal。例如，Swing客户端可能需要一个Java Virtual Machine中的所有线程都使用同样的安全上下文（security context）。在这种情况下你要使用SecurityContextHolder.MODE_GLOBAL模式。另外一些应用程序可能需要安全线程产生的线程拥有同样的安全标识符（security identity）。这可以通过SecurityContextHolder.MODE_INHERITABLETHREADLOCAL来实现。你可以通过两种方法来修改默认的SecurityContextHolder.MODE_THREADLOCAL。第一种是设置一个系统属性。或者，调用 SecurityContextHolder的一个静态方法。大部分的应用程序不需要修改默认值，不过如果你需要，那么请查看 SecurityContextHolder的JavaDocs获取更多信息。

我们在SecurityContextHolder中存储当前和应用程序交互的principal的详细信息。Acegi Security使用一个Authentication对象来代表这个信息。尽管你通常不需要自行创建一个Authentication对象，用户还是经常会查询Authentication对象。
------解决方案--------------------
Acegi没用过。。。帮顶。。。
------解决方案--------------------
路过
------解决方案--------------------
考考考
??的法宝
分分分
??的命根
-_-b
------解决方案--------------------
看看
------解决方案--------------------
up
------解决方案--------------------
up
------解决方案--------------------
你对技术得理解透彻
------解决方案--------------------
饿地神啊
------解决方案--------------------
路过...
------解决方案--------------------
我接分，难道不给么？
------解决方案--------------------
关注一下
------解决方案--------------------
up
------解决方案--------------------
深奥
------解决方案--------------------
呵呵！！！
------解决方案--------------------
不懂
------解决方案--------------------
关注！
------解决方案--------------------
mark