[JBoss JIRA] Created: (JBCACHE-785) InvocationContext and suspended transactions
by Owen Taylor (JIRA)
InvocationContext and suspended transactions
--------------------------------------------
Key: JBCACHE-785
URL: http://jira.jboss.com/jira/browse/JBCACHE-785
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: Owen Taylor
Assigned To: Manik Surtani
The attached test case demonstrates that if you:
A) Make calls to the tree cache
B) suspend the current transaction
C) Make more calls to the tree cache
The locks created at step C) are sometimes attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBCACHE-745) nodeEvicted being called for nodes that don't actuall get evicted
by gregorypierce (JIRA)
nodeEvicted being called for nodes that don't actuall get evicted
-----------------------------------------------------------------
Key: JBCACHE-745
URL: http://jira.jboss.com/jira/browse/JBCACHE-745
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: gregorypierce
Assigned To: Manik Surtani
Attachments: CacheEviction.java
Working on class example from training materials CacheEviction.java. Will receive a nodeEvicted call that the root node has been evicted, but if you look at the console itself and print the tree - the root node doesn't get evicted. Should not call nodeEvicted with a node that hasn't actually already been evicted from the tree. Looks like it realizes that the node is a parent node and decides against evicting it after the interface call.
// FIXME We extend AbstractTreeCacheListener, which provides a default implementation
// of the TreeCacheListener interface. You just need to override methods to write to
// the console for cache events in which you are interested. Do something like this:
public void nodeCreated(Fqn fqn) {
System.out.println("nodeCreated(): fqn: " +fqn);
}
public void nodeEvicted(Fqn fqn)
{
System.out.println("nodeEvicted(): fqn: " +fqn);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBPM-741) JbpmSchedulerThread does not terminate the scheduler/command threads properly
by Alejandro Guizar (JIRA)
JbpmSchedulerThread does not terminate the scheduler/command threads properly
-----------------------------------------------------------------------------
Key: JBPM-741
URL: http://jira.jboss.com/jira/browse/JBPM-741
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.1
Reporter: Alejandro Guizar
Fix For: jBPM 3.1.3
The implementation of SchedulerThread and CommandExecutorThread in 3.1.1 does not provide a mechanism to exit the run() method, allowing the Thread to exit properly and release any resources it is holding.
This becomes an issue for perm gen in JBoss AS and other containers.
For SchedulerThread, keepRunning (bool) should be public or provide mutators, so whatever launches the Thread can modify it.
For CommandExecutorThread, the while(true) in run() should be changed to something like SchedulerThread uses and, of course, provide mutators to the loop control variable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBPM-696) Field Instanciator problems
by Shai Bentin (JIRA)
Field Instanciator problems
---------------------------
Key: JBPM-696
URL: http://jira.jboss.com/jira/browse/JBPM-696
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.1
Environment: WinXP, Linux running on JBoss Application Server 4.0.3SP1, JDK1.5.0_06
Reporter: Shai Bentin
Assigned To: Tom Baeyens
Priority: Minor
Fix For: jBPM 3.1.2
The method getValue() is see two problems, one is jdk5 related the other is just an idea.
In jdk5 doing if (type.isAssignableFrom(Set.class)) and such yields a 'false' even when it is supposed to be true...
if we would write the same if in reverse:
Set.class.isAssignableFrom(type) we will ge the desired reuslt.
The other issue is, if we know the super type why do we impose a specific implementation, i.e. if we have a Collection, why do we impose an ArrayList. We have the user's type and we know it is of type collection so why don't we instanciate the requested type....
Here is how I propose to write this method:
public static Object getValue(Class type, Element propertyElement) {
// parse the value
Object value = null;
try {
if ( type == String.class ) {
value = propertyElement.getText();
} else if ( (type==Integer.class) || (type==int.class) ) {
value = new Integer( propertyElement.getTextTrim() );
} else if ( (type==Long.class) || (type==long.class) ) {
value = new Long( propertyElement.getTextTrim() );
} else if ( (type==Float.class ) || (type==float.class) ) {
value = new Float( propertyElement.getTextTrim() );
} else if ( (type==Double.class ) || (type==double.class) ) {
value = new Double( propertyElement.getTextTrim() );
} else if ( (type==Boolean.class ) || (type==boolean.class) ) {
value = Boolean.valueOf( propertyElement.getTextTrim() );
} else if ( (type==Character.class ) || (type==char.class) ) {
value = new Character( propertyElement.getTextTrim().charAt(0) );
} else if ( (type==Short.class ) || (type==short.class) ) {
value = new Short( propertyElement.getTextTrim() );
} else if ( (type==Byte.class ) || (type==byte.class) ) {
value = new Byte( propertyElement.getTextTrim() );
} else if (List.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (List)type.newInstance());
} else if (Set.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (Set)type.newInstance());
} else if (Collection.class.isAssignableFrom(type)) {
value = getCollection(propertyElement, (Collection)type.newInstance());
} else if (Map.class.isAssignableFrom(type)) {
value = getMap(propertyElement, (Map)type.newInstance());
} else if ( type==Element.class ) {
value = propertyElement;
} else {
Constructor constructor = type.getConstructor(new Class[]{String.class});
if ( (propertyElement.isTextOnly())
&& (constructor!=null) ) {
value = constructor.newInstance(new Object[]{propertyElement.getTextTrim()});
}
}
} catch (Exception e) {
log.error("couldn't parse the bean property value '" + propertyElement.asXML() + "' to a '" + type.getName() + "'" );
throw new JbpmException( e );
}
return value;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months
[JBoss JIRA] Created: (JBPM-758) DbPersistenceService needs update for new Hibernate version
by Thomas Klute (JIRA)
DbPersistenceService needs update for new Hibernate version
-----------------------------------------------------------
Key: JBPM-758
URL: http://jira.jboss.com/jira/browse/JBPM-758
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM 3.1.2
Environment: jboss AS 4.0.4, hibernate 3.1 or hibernate 3.2
Reporter: Thomas Klute
Assigned To: Tom Baeyens
Fix For: jBPM 3.1.3
Release of JDBC connections changed with hibernate version > 3.0.
DbPersistenceService now throws exception when trying to close a hibernate session (because in was closed automatically when the transaction committed).
The exception happens every few seconds when using the jbpm scheduler-service.
See below for stack trace.
See http://www.hibernate.org/250.html#A31 for a detailed description of hibernate-changes regarding JDBC connections.
FYI: The exception does not roll back the transaction, because it has already been committed.
Please adapt the code to the new hibernate behaviour. Maybe just comment out the "throw" of the exception.
I have no idea what code would work with old _and_ new hibernate versions.
We just got the problem integrating jbpm into a jboss AS 4.0.4 using hibernate 3.2.
...
2006-09-28 16:11:53,996 DEBUG [org.jbpm.persistence.db.DbPersistenceService] creating hibernate session
2006-09-28 16:11:53,998 DEBUG [org.hibernate.jdbc.JDBCContext] TransactionFactory reported no active transaction; Synchronization not registered
2006-09-28 16:11:53,998 DEBUG [org.hibernate.impl.SessionImpl] opened session at timestamp: 4749118316527616
2006-09-28 16:11:53,998 DEBUG [org.jbpm.persistence.db.DbPersistenceService] beginning hibernate transaction
2006-09-28 16:11:53,998 DEBUG [org.hibernate.transaction.JTATransaction] Looking for UserTransaction under: UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] Obtained UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] begin
2006-09-28 16:11:54,000 DEBUG [org.hibernate.transaction.JTATransaction] Began a new JTA transaction
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.JDBCContext] successfully registered Synchronization
2006-09-28 16:11:54,000 DEBUG [org.jbpm.scheduler.impl.SchedulerThread] checking for timers
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC connection
2006-09-28 16:11:54,000 DEBUG [org.hibernate.SQL] select timer0_.ID_ as col_0_0_ from JBPM_TIMER timer0_ where (timer0_.EXCEPTION_ is null) and timer0_.ISSUSPENDED_<>1 order by timer0_.DUEDATE_ asc
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open ResultSet (open ResultSets: 0, globally: 0)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] exhausted results
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] closing iterator
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close ResultSet (open ResultSets: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively releasing JDBC connection
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
2006-09-28 16:11:54,001 DEBUG [org.jbpm.JbpmContext] closing JbpmContext
2006-09-28 16:11:54,002 DEBUG [org.jbpm.svc.Services] closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService@15a9173
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] committing hibernate transaction
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] commit
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] Committed JTA UserTransaction
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.svc.Services.close(Services.java:211)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.JbpmContext.close(JbpmContext.java:139)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
2006-09-28 16:11:54,002 ERROR [STDERR] at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
2006-09-28 16:11:54,003 ERROR [STDERR] Caused by: org.hibernate.SessionException: Session was already closed
2006-09-28 16:11:54,003 ERROR [STDERR] at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
2006-09-28 16:11:54,003 ERROR [STDERR] at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
2006-09-28 16:11:54,003 ERROR [STDERR] ... 4 more
2006-09-28 16:11:54,003 ERROR [org.jbpm.svc.Services] problem closing service 'persistence'
org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
at org.jbpm.svc.Services.close(Services.java:211)
at org.jbpm.JbpmContext.close(JbpmContext.java:139)
at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.hibernate.SessionException: Session was already closed
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
... 4 more
2006-09-28 16:11:54,003 INFO [org.jbpm.scheduler.impl.SchedulerThread] runtime exception while executing timers
org.jbpm.JbpmException: problem closing services {persistence=org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session}
at org.jbpm.svc.Services.close(Services.java:223)
at org.jbpm.JbpmContext.close(JbpmContext.java:139)
at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
at org.jbpm.svc.Services.close(Services.java:211)
... 3 more
Caused by: org.hibernate.SessionException: Session was already closed
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
... 4 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 7 months