| « | September 2025 | » | | 日 | 一 | 二 | 三 | 四 | 五 | 六 | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | | | | | |
|
公告 |
| 本博客在此声明所有文章均为转摘，只做资料收集使用。并无其他商业用途。 |
| Blog信息 |
|
blog名称:
日志总数:210
评论数量:205
留言数量:-19
访问次数:922483
建立时间:2007年5月10日 |
| |
|
 [内容管理框架]Jackrabbit 笔记：Sharing a Session or a Session per web user
文章收藏, 网上资源, 软件技术, 电脑与网络
李小白 发表于 2008/4/9 9:08:29 |
|
Paco AvilaWed, 21 Nov 2007 08:16:24 -0800
Hi
Our application using Jackrabbit is an Document Management System
(OpenKM). Actually we prevent an user log into the web aplication twice,
so there is only one Jackrabbit Session per web user.
But we also expose several methods via WebServices and here is the
problem: if an user is logged into the web application, the same user
can't user WebService API because he is already logged into the system.
I have think two options:
- Reuse an existing Jackrabbit Session for both web user and the same
ws api user. PROBLEM: is it a good practice for Jackrabbit?
- The web user hace one JR Session and the ws api user have another
session. PROBLEM: Every web user need another WS user and this can be
hard to manage because we need to set permissions for both users and
should be the same permissions for them.
Any tip?
--
Re: Sharing a Session or a Session per web userAlexandru Popescu ☀Wed, 21 Nov 2007 10:39:27 -0800Paco, as you probably know by now, jcr Sessions are not thread safe,
and so exposing them in a multi-thread environment may become a risk
for the data. I am not sure how your application is behaving and how
do you protect against thread contention at the session level, so it
is kind of hard to give an advise. What I can share is the fact that
in a read-only mode you can probably share a session between different
threads.
Re: Sharing a Session or a Session per web userJukka ZittingMon, 26 Nov 2007 08:28:03 -0800Hi,
On Nov 26, 2007 4:27 PM, qcfireball <[EMAIL PROTECTED]> wrote:
> Question: what is the maximum number of concurrent read-only uses of a
> Session would you recommend? 10 / 50 / 100 / no limit?
Personally I'd recommend allowing only a single concurrent thread to
use a session. Even though multiple concurrent threads may work fine
with current Jackrabbit, this hasn't really been very well verified
and some of the cache data structures might well hide serious
concurrency issues. It is also possible, perhaps even likely, that in
some future release Jackrabbit will start explicitly synchronizing
access to a session to simplify and streamline internal locking
mechanisms.
BR,
Jukka Zitting
Re: Sharing a Session or a Session per web userJukka ZittingMon, 26 Nov 2007 08:39:25 -0800Hi,
On Nov 21, 2007 6:15 PM, Paco Avila <[EMAIL PROTECTED]> wrote:
> Our application using Jackrabbit is an Document Management System
> (OpenKM). Actually we prevent an user log into the web aplication twice,
> so there is only one Jackrabbit Session per web user.
Note that binding a JCR session to a HTTP session might still be
troublesome, as the Servlet API allows a single session to have
multiple concurrent HTTP requests. I would recommend either using
separate JCR sessions per each HTTP request or explicitly
synchronizing all JCR session access in your application.
> But we also expose several methods via WebServices and here is the
> problem: if an user is logged into the web application, the same user
> can't user WebService API because he is already logged into the system.
For such cases I would recommend using separate JCR sessions per each request.
> - Reuse an existing Jackrabbit Session for both web user and the same
> ws api user. PROBLEM: is it a good practice for Jackrabbit?
You can do that, but my recommendation is then to explicitly
synchronize access to the JCR session in your application. Something
like this:
// your application code
...
synchronized (session) {
... // any code that uses the JCR session
}
...
This will obviously become a bottleneck if you want to concurrently
serve multiple requests for the same user.
> - The web user hace one JR Session and the ws api user have another
> session. PROBLEM: Every web user need another WS user and this can be
> hard to manage because we need to set permissions for both users and
> should be the same permissions for them.
There's no reason why you could not open multiple sessions for a
single user. You could have separete web user and ws api user sessions
for the same JCR user account, or even start separate sessions for
each individial HTTP request.
The only functional benefit from keeping a JCR session across
individual HTTP requests is that you can then use the transient space
to manage unsaved changes (for example an uncommitted shopping cart).
If startup overhead of a JCR session is a problem for your
application, you can also consider using a session pool.
Unfortunately, as of now Jackrabbit doesn't come with a built-in
session pool implementation, but implementing one using something like
commons-pool shouldn't be too difficult (assuming you have some
control over the behaviour of your application).
BR,
Jukka Zitting
|
|
|