User: starksm
Date: 02/04/18 06:22:48
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_3_0
AbstractInstanceCache.java
Log:
The call to register with the passivation thread was lost in the last change.
This restores the registration.
Revision
User: starksm
Date: 02/04/18 06:39:12
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
Log:
The call to register with the passivation thread was lost in the last change.
This restores the registration.
Revision ChangesPath
1.32 +6 -2
User: starksm
Date: 02/04/17 13:17:56
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_3_0
AbstractInstanceCache.java EntityInstanceCache.java
StatefulSessionInstanceCache.java
Log:
The NPE in the passivation thread was not fixed
User: starksm
Date: 02/04/17 13:19:20
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
EntityInstanceCache.java
StatefulSessionInstanceCache.java
Log:
The NPE in the passivation thread was not fixed by not-nulling
User: patriot1burke
Date: 02/02/21 13:45:18
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstanceCache.java
Log:
do not obtain a reference to the BeanLock on a get. Causes memory leaks and problems
Revision ChangesPath
No
User: d_jencks
Date: 02/02/21 20:24:55
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
AbstractInstancePool.java MetricsInterceptor.java
Log:
Made classes visible across all subpackages in a deployment such as an ear. (bug
520676.
User: patriot1burke
Date: 02/01/30 16:06:53
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
Log:
do not grab a reference to a BeanLock on cache insert. What we're really only saving
is an allocation of a small BeanLock object and this adds headaches in making
User: lqd
Date: 02/01/17 09:39:35
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstanceCache.java
Log:
fix for SF bug #504895: removeLockRef() is not called when release()-ing
the bean
Revision ChangesPath
No
User: patriot1burke
Date: 01/12/03 13:47:55
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstanceCache.java
Log:
Added a little defensive coding.
Make sure that the ctx.getId() returned from unschedulePassivation is NOT null.
I just
User: patriot1burke
Date: 01/12/03 14:04:29
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
Log:
Added a little defensive coding.
Make sure that the ctx.getId() returned from unschedulePassivation is NOT null.
I just debugged this behavior in JBoss 2.2.x
User: starksm
Date: 01/11/26 17:16:21
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstanceCache.java
Log:
Use a single daemon thread to passivate all EJBs rather than a thread
per container as this is wasteful of threads, especially
User: starksm
Date: 01/11/26 20:25:11
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
AbstractInstanceCache.java
Log:
There is no need to keep the class loader with the passivation job instance.
Revision ChangesPath
No
User: starksm
Date: 01/11/26 20:23:16
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
Log:
Change AbstractInstanceCache to use a single passivator thread for
all deployed EJBs as a thread per container is wasteful and kills
large deployments on systems with
User: starksm
Date: 01/11/25 19:12:26
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
AbstractInstancePool.java AbstractInterceptor.java
AbstractTxInterceptor.java
User: starksm
Date: 01/09/11 11:35:00
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
AbstractInterceptor.java AbstractTxInterceptor.java
AbstractTxInterceptorBMT.java
A little more investigation shows that jboss-management.jar has this file
compiled in but it still isn't in cvs. Why do you check in a jar for
classes in the jboss project? Isn't it built whenever you build jboss?
Also, where can I find the management package? Did you choose this
package name?
] CVS update:
jboss/src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
AbstractInstancePool.java BMPPersistenceManager.java
CMPPersistenceManager.java EntityInstancePool.java
LRUEnterpriseContextCachePolic
A little more investigation shows that jboss-management.jar
has this file
User: schaefera
Date: 01/07/20 13:07:16
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
AbstractInstancePool.java
BMPPersistenceManager.java
CMPPersistenceManager.java EntityInstancePool.java
PROTECTED]
|Sent: Wednesday, June 27, 2001 1:38 AM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins
|AbstractInstanceCache.java
|
|
| User: mnf999
| Date: 01/06/26 22:37:43
|
| Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
| Log
PROTECTED]]On Behalf Of
||[EMAIL PROTECTED]
||Sent: Wednesday, June 27, 2001 1:38 AM
||To: [EMAIL PROTECTED]
||Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins
||AbstractInstanceCache.java
||
||
|| User: mnf999
|| Date: 01/06/26 22:37:43
||
|| Modified:src/main/org
User: patriot1burke
Date: 01/06/17 07:57:53
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
Log:
In PassivatorJob, check to see if ctx.getId() is null just in case the ctx has
already been passivated.
Added key parameter to canPassivate(..) so that it
User: patriot1burke
Date: 01/06/15 16:35:05
Modified:src/main/org/jboss/ejb/plugins AbstractInstanceCache.java
Log:
We can't rely on the EnterpriseContext to provide PassivationJob
with a valid key because it may get freed to the InstancePool, then
reused before the
22 matches
Mail list logo
