[
https://issues.jboss.org/browse/JBSEAM-4861?page=com.atlassian.jira.plugi...
]
ahus1 updated JBSEAM-4861:
--------------------------
Description:
Whenever getInstanceFromFactory() is called and a factory is used, a (application wide)
lock is used: factoryLock.
In my environments the Factory uses expensive calls to the backend to create an object,
and during this time no other Factory method is allowed to be called. This is a severe
bottleneck in a multiuser environment.
This lock is important for APPLICATION scoped components, but other components that are
i.e. CONVERSATION scoped, Seam already ensures that only one Thread has access to the
current conversation. The same should be true for PAGE and EVENT. In this cases no lock
should be acquired. UPDATE: Factories that use injection should not be called
multithreaded, therefore an updated condition.
See the follwing code snippet. I also attach a patch.
I tested the patch for Seam 2.2.2.Final - I would be most happy to have this included in
2.2 and 2.3 branch.
Br Alexander.
<code>
ScopeType scopeResult = getOutScope(factoryMethod.getScope(),
factoryMethod.getComponent());
ScopeType scopeFactory = factoryMethod.getComponent().getScope();
boolean lockingNeeded = false;
/*
* we need this lock in the following cases: (1) the target scope is
* accessed by more than one thread (as we don't want to create the same
* object by two threads at the same time for the same scope) OR (2) the
* factory is accessed by more than one thread and is using interceptors
* (as accessing a factory multiple times might mess up interceptors).
* This assumes that (1) the scopes CONVERSATION, EVENT and PAGE can't
* be accessed by more than one thread anyway due to CONVERSATION being
* locked for the current thread anyway, and EVENT and PAGE being only
* short-lived anyway. (2) a factory that doesn't use injection can be
* accessed multi threaded. See JBSEAM-4669/JBSEAM-2419 for the original
* discussion.
*/
if ((scopeResult != ScopeType.CONVERSATION
&& scopeResult != ScopeType.EVENT && scopeResult !=
ScopeType.PAGE)
|| (scopeFactory != ScopeType.CONVERSATION
&& scopeFactory != ScopeType.EVENT
&& scopeFactory != ScopeType.PAGE && factoryMethod
.getComponent().interceptionEnabled)) {
lockingNeeded = true;
// one lock per factory might be optimal
factoryLock.lock();
}
try
{
...
}
finally
{
if (lockingNeeded) {
factoryLock.unlock();
}
}
</code>
was:
Whenever getInstanceFromFactory() is called and a factory is used, a (application wide)
lock is used: factoryLock.
In my environments the Factory uses expensive calls to the backend to create an object,
and during this time no other Factory method is allowed to be called. This is a severe
bottleneck in a multiuser environment.
This lock is important for APPLICATION scoped components, but other components that are
i.e. CONVERSATION scoped, Seam already ensures that only one Thread has access to the
current conversation. The same should be true for PAGE and EVENT. In this cases no lock
should be acquired.
See the follwing code snippet. I also attach a patch.
I tested the patch for Seam 2.2.2.Final - I would be most happy to have this included in
2.2 and 2.3 branch.
Br Alexander.
ScopeType s = getOutScope(factoryMethod.getScope(),
factoryMethod.getComponent());
if (s != ScopeType.CONVERSATION && s != ScopeType.EVENT
&& s != ScopeType.PAGE) {
factoryLock.lock();
}
try {
/* **** */
} finally {
if (s != ScopeType.CONVERSATION && s != ScopeType.EVENT
&& s != ScopeType.PAGE) {
factoryLock.unlock();
}
}
Component.java uses application wide factoryLock too often
-----------------------------------------------------------
Key: JBSEAM-4861
URL:
https://issues.jboss.org/browse/JBSEAM-4861
Project: Seam 2
Issue Type: Patch
Components: Core
Affects Versions: 2.2.2.Final, 2.3.0.ALPHA
Reporter: ahus1
Attachments: Component.patch, Component.patch
Whenever getInstanceFromFactory() is called and a factory is used, a (application wide)
lock is used: factoryLock.
In my environments the Factory uses expensive calls to the backend to create an object,
and during this time no other Factory method is allowed to be called. This is a severe
bottleneck in a multiuser environment.
This lock is important for APPLICATION scoped components, but other components that are
i.e. CONVERSATION scoped, Seam already ensures that only one Thread has access to the
current conversation. The same should be true for PAGE and EVENT. In this cases no lock
should be acquired. UPDATE: Factories that use injection should not be called
multithreaded, therefore an updated condition.
See the follwing code snippet. I also attach a patch.
I tested the patch for Seam 2.2.2.Final - I would be most happy to have this included in
2.2 and 2.3 branch.
Br Alexander.
<code>
ScopeType scopeResult = getOutScope(factoryMethod.getScope(),
factoryMethod.getComponent());
ScopeType scopeFactory = factoryMethod.getComponent().getScope();
boolean lockingNeeded = false;
/*
* we need this lock in the following cases: (1) the target scope is
* accessed by more than one thread (as we don't want to create the same
* object by two threads at the same time for the same scope) OR (2) the
* factory is accessed by more than one thread and is using interceptors
* (as accessing a factory multiple times might mess up interceptors).
* This assumes that (1) the scopes CONVERSATION, EVENT and PAGE can't
* be accessed by more than one thread anyway due to CONVERSATION being
* locked for the current thread anyway, and EVENT and PAGE being only
* short-lived anyway. (2) a factory that doesn't use injection can be
* accessed multi threaded. See JBSEAM-4669/JBSEAM-2419 for the original
* discussion.
*/
if ((scopeResult != ScopeType.CONVERSATION
&& scopeResult != ScopeType.EVENT && scopeResult !=
ScopeType.PAGE)
|| (scopeFactory != ScopeType.CONVERSATION
&& scopeFactory != ScopeType.EVENT
&& scopeFactory != ScopeType.PAGE && factoryMethod
.getComponent().interceptionEnabled)) {
lockingNeeded = true;
// one lock per factory might be optimal
factoryLock.lock();
}
try
{
...
}
finally
{
if (lockingNeeded) {
factoryLock.unlock();
}
}
</code>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira