January 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Any possibility of persistence-API?

by tom.baeyens＠jboss.com

"wkzk" wrote : Hi. | I ve chosen iBatis or another light persistent API as a persistent / data access framework. | So, I'd like to use jBPM with above oss frameworks, not hibernate. | can you elaborate on this motivation. the only motivation that i have seen in this context is that from a coding perspective, this looks cleaner. but in fact the downsides are much bigger. 1) the api would have to be reduced to the intersection of what hibernate, jpa, ibatis and all other potential persistent stores would offer. another way to make this point is that we say: there is such an api! the interface is called org.hibernate.Session. go and implement it with iBatis. probably you realize that is not going to be a trivial job. that is the same work that you ask us to do when you ask us for a persistence SPI. 2) it would be impossible to do the QA on a matrix of JDK, DB and persistence framework 3) we provide nice integrations with hibernate, but you can always ignore those and consider hibernate a jbpm implementation detail. in which case, the only thing that comes out of jbpm is a JDBC connection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204218#4204218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204218

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - How to stop the unwanted instance not related to jboss porta

by peris

Hi , I am using jboss portal , but it isvery slow. I think that we can stop the unwanted instance not related to jboss portal(EJB, etc). So please guide me to stop the instance. Thanks in advance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204213#4204213 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204213

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Portlet User management

by peris

Hi Please explain or give some idea or give any link to learn about portlet user management. Thanks in advance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204209#4204209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204209

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JMSTests are broken...

by clebert.suconic＠jboss.com

jmesnil: Never mind... I thought it was something complex, when it was actually this :-) http://fisheye.jboss.org/browse/Messaging/trunk/src/config/jbm-configurat... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204187#4204187 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204187

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Any possibility of persistence-API?

by brittm

anonymous wrote : For instance, in JBPM3, you could have a rollback that would obliterate some or all of the activity on other "tines" of a fork. Everything is in sync, but the behavior is probably unexpected. One way to mitigate the "roll back all 30 branches of execution" is to place async "save" points in your process--whether by jBPM's own async feature, or your own JMS functionality. This way, the process would persist itself before continuing. If you had a roll back on one branch, you'd just roll back to the save point for that branch. This way, the process has a 'plan' for managing transaction scope. Since we should all be catching reasonably expected exceptions, a failure to commit should be an extraordinary event in which there is no certainty of what went wrong. In such a case, the only safe response is to roll back the entire transaction to some manageable point--preferably where you started. Sure, some JMS integration messages may have gone out the door, but they're all tagged with a business key/id that would allow them to be resent without causing trouble (right?) So in my line of thinking, I would definitely want everything rolled back and in sync. Unfortunately, many of our use cases aren't limited to two transactions. As the signalled process moves back and forth gathering or updating data in the domain, the XA can wrap several transactions. For instance 1) Domain updates data and signals process 2) Process execution sets status at some point on domain objects (e.g. inProgress) 3) Process execution continues 4) Process reads domain objects for decision making, forking, etc. 5) Process updates status on domain objects (e.g. inService) 6) XA finally commits These issues became large enough that we no longer start processes directly from the domain application--all initial signalling of new process instances is now done via JMS. (The domain creates and prepares the process instance, but uses JMS to signal out of the Start state.) But this only addresses the first hand-off between transactions; if, in the same execution, the process itself updates the domain then later tries to read the same domain table row (for example, from two different ActionHandlers), the we have the deadlock again because we're utilizing different DB connections. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204186#4204186 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204186

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - Re: run jboss esb on tomcat

by vdruzh

I successfully build war file and deploy on tomcat. But I found out that this web application uses some system properties for starting. I mean class org.jboss.soa.esb.servlet.ConfigListener. I concern only how my changes can affect other packages which are used by jboss esb. I also found if I need to deploy 2 or more esb services I need to run to web applications: one war - one esb. Does anyone run more than one esb service on tomcat? And what I lost if I use tomcat instead of jboss esb server? Regards, Vlad View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204183#4204183 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204183

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: MultiThreadFailoverTest removed on build.xml

by clebert.suconic＠jboss.com

I have set the stress-tests on hudson, with 20. So, the integration-tests are running with iterations=1. Right now the stress-test is set to run daily at 2:00 AM EST. Feel free to start runs manually when you do any major commits... or change the build on hudson if you feel we need it more frequently. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204182#4204182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204182

17 years, 2 months

1
0
0 / 0

[Design of JBoss ESB] - run jboss esb on tomcat

by vdruzh

Hi, I wonder does anyone tried to deploy jboss esb on tomcat using jbpm and some esb services. Thanks in advance Vlad. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204173#4204173 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204173

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - JMSTests are broken...

by clebert.suconic＠jboss.com

Jeff... just to let you know.. JMSTests are broken. I believe you would be able to fix it real quick... as you know what you have changed on the XML schemas. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204137#4204137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204137

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Any possibility of persistence-API?

by estaub

Britt, Nice post! This area can always use more thought. The one pushback I see (and it's major), is that when a domain business method fails and rolls back, it's painful for that to roll back the workflow persistence operations as well. The amount that is rolled back is essentially unpredictable, since it depends on details of the engine's implementation that probably should not be specified or relied on. For instance, in JBPM3, you could have a rollback that would obliterate some or all of the activity on other "tines" of a fork. Everything is in sync, but the behavior is probably unexpected. Of course, in the two-transaction model, you can have the JBPM transaction roll back, while the business methods have already committed - the inverse of the problem described above. But I think this is a lesser problem. -Ed Staub View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204098#4204098 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204098

17 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2009