As I find it hard to understand code without knowing the intent of the authors, and somehow Q&A seems to help me, I'm starting this thread on high-level concepts such as scoping, containership, thread safety, transactions, etc. as pertains to jBPM. I'm trying to get some kind of model in my head of the software in order to apply it with best practices. Examples are good, but you need a lot of them to fully describe all the possibilities. I'd like to get a better understanding of the design philosophy of jBPM code to better understand how to configure it and use the objects and API effectively. ----------------------------- General Discussion ------------------------ I'm going to state some stuff, probably wrong, and welcome corrections in the spirit of a dialog to help understand the concepts behind jBPM. What is hard for me to grasp from browsing the API is the scoping and role of objects such as process definitions, process instances, tasks, task instances, even JbpmConfigurations and JbpmContexts. It seems a JbpmConfiguration determines which "services" are used when a JbpmContext instance is created. This includes the "persistance service". I can imagine that someone could develop a persistance service that uses more than one database, so there is no assumption that a JbpmConfiguration is mapped to a particular database. But I think a JbpmConfiguration is mapped to a single persistance service. The JbpmContext instance is created from a particular JbpmConfiguration instance, and exposes "some services" for use in the workflow processing. I see that we can create a JbpmContext with a name as well, by using Code: JbpmConfiguration.createJbpmContext(java.lang.String name) -- what does that mean? Can transactions in JbpmContexts with different names occur simultaneously (without conflict). A service of great interest is the "persistance" service, which theoretically should be abstract so we never should need to know how it works and we should never need to access a database directly, etc. The JbpmContext instance magically seems to create a transaction encompassing the various "instance" objects that we create with the JbpmContext instance object and interact with (ProcessInstance, TaskInstance, etc.). A JbpmContext instance seems to be related to a concept called a "session", which implies some kind of connection and related transaction processing ability. I think the confusion I have is thinking that JbpmConfigurations and JbpmContexts are somehow containers for workflow objects, but they are not. The objects exist in the persistance system (typically a database), and I guess it would be possible for different JbpmConfigurations to provide services that access the same objects. So there is no real "container" for workflow objects at the API level, you can access them by name and/or Id, although the persistance layer is probably intended to serve as a container. I'm not saying I'd want to do this, but theoretically I could configure two different persistance mechanisms to access the same database using the same table names and other conventions. Then I could create two different JbpmConfiguration objects based on these two different services. I could use one configuration and a JbpmContext instance to deploy a ProcessDefinition and create a new ProcessInstance. I could (maybe) then use the second configuration and a JbpmContext instance to retrieve that ProcessInstance by Id and work with it. Or could I? That is a question. Does a JbpmContext know whether a ProcessDefinition has been deployed by a JbpmContext created from the same (or different) JbpmConfiguration? Or does it matter? In other words, is there any real containership implied by a JbpmConfiguration? Normally I would think that if I deploy a ProcessDefinition with a particular JbpmConfiguration (using a JbpmContext created from that JbpmConfiguration), then I could only access that ProcessDefinition or instances of it using a JbpmContext created from the same JbpmConfiguration -- but I'm not sure. Ok, that's as far as I can get with this. I'd like to hear others' understanding of the jBPM concepts. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045046#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...