Just wanted to clarify sonnyboy73's last post.
This exception occurs if an HTTP request is sent to the AJP connector port.
This port is specified in the
$SERVER_HOME/server/$CONFIG/deploy/jbossweb-tomcat55.sar/server.xml file.
View the original post :
http://www.jboss.com/index.html?module
It has been pointed out to me that not closing the jbpmSession can be a bad
thing in a multithreaded environment. JbpmSession's close method includes a
call to popCurrentSession() which should be called or a memory leak may occur.
View the original post :
http://www.jboss.com/index.html?modul
Alex,
Thanks for the reply. I had forgotten about popCurrentSession() being in the
close() method.
So, for now I will be forced to use:
jbpmSession.beginTransaction();
jbpmSession.commitTransaction();
jbpmSession.close();
Zac
View the original post :
http://www.jboss.com/index.html?module=b
I've found that not closing the JbpmSession object will allow the EJB container
the opportunity to close and flush the associated hibernate session.
Make sense?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3916745#3916745
Reply to the post :
http://www.jb
It appears my only mistake was in closing the jbpmSession and not allowing the
system to take care of it for me.
Calling the SSBs sessionContext.setRollbackOnly() had the expected result of
not persisting the processInstance.
Does anyone know if not closing the jbpmSession will have any adverse
Hi Ranier,
anonymous wrote : f the processInstance is being commited (persisted) that
should be what you are expecting or isn't it?
Yes I expect the processInstance to be committed when flush/commitTransaction
is invoked.
I don't think I should have to call session.flush() or
jbpmSession.commi
Rainer,
I have tried explicitly flushing, this results in the changes to the process
instance being persisted. I have not tried adding begin/end transaction as I'm
hoping to avoid any explicit transaction demarcation code.
Based upon http://hibernate.org/42.html#A7 I believe it is possible to
Whoops, meant to hit preview, not submit.
The following code is being run from a CMT SSBean. I see Hibernate running a
bunch of select statements before the save method is called. After the save,
however, I don't see any insert or update statements. This makes me feel that
I've misconfigured
Hello,
I've been unable to successfully configure JBPM/Hibernate to rely upon the EJB
container for transaction demarcation.
My Environment:
JBoss 4.0.2
Hibernate 3.0.5
JBPM 3.0.2
JDK 1.5 on Solaris
jbpm.properties
| jbpm.log.package.org.jbpm=info
| jbpm.log.package.org.jbpm.persistence
Hibernate Sessions and Transactions are documented here
http://www.hibernate.org/42.html.
Important to note this only applies to 3.1.x Hibernate versions.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3915575#3915575
Reply to the post :
http://www.jboss
| [TransactionManagerLookupFactory] No TransactionManagerLookup configured
(in a JTA environment, use of read-write or transactional second-level cache is
not recommended)
|
Does anyone know what this means and how to correct it? It sounds like
something is misconfigured.
I'm running
I was able to deploy a par using the DeployParTask. Here is a snippet from my
ant script.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The conte
"guy.walker" wrote : I think it might be in org.jbpm.jpdl.par, the class is
called ProcessArchiveDeployer
|
I don't think so. ProcessArchiveDeployer is not extending an Ant taskdef.
I'm inclined to believe that the org.jbpm.ant.DeployParTask is what we're
looking for.
/**
| * ant task f
13 matches
Mail list logo
