I admire your enthousiasm, but you should (imo) less ask why and do some investigation. If you follow the code of deployProcessDefinition() (which takes a parameter btw) you'll immediately get to the GraphSession.deployProcessDefinition(....) and surprise surprise... there is a session.save(processdefinition). I myself found that in less than 5 seconds... and opening a JbpmContext opens a session in a transaction if one is configured or already running. So you should still close the context and all is fine.
So the method is in the right place.....
I appreciate the discussion.
There is some critical mass of knowledge you need to understand the persistence aspects of JBPM. Pulling a GraphSession out of a JbpmContext and calling "save()" could mean anything. Where does the transaction start and end? What gets rolled back when you when you call JbpmContext.setRollbackOnly()? Every API needs a contract, a set of documented rules that defines a model and how the model is affected. Reverse-engineering it from code is really unproductive except to clarify special cases. All us newcomers are in the same boat until the developers really document it.
Some thing work the way they work. If you want to put them up for discussion, I think you should do more investigation befor just 'posing a statement', wich is imo what you do. There is lots of info on transactions, jbpm and hibernate. You just have to do a little homework which can even be done without reverseengineering!!!!
I personally have limited amount of time and tend to help others out more than these (imo) less relevant and unfounded discussions.
With regard to the newcomers, you are the *first* to put this up for discussion, so it clearly is not relevant for others.
Every API needs a contract, a set of documented rules that defines a model and how the model is affected.
As far as I can see, the kind of documentation you're looking for won't happen in this project until either:
- there's some immediate, undeniable business imperative for JBoss, like a big customer demanding it. I am hopeful - it's pretty scary to be basing commercial product on something whose behavior I know well only where I've dug hard into the code. Presumably some major customer will have the same misgivings.
- folks come up with a clean way for it to be incrementally contributed to by users. Since the doc at the level you're looking for is classically in the javadoc, that's hard, because it requires either committer access or for someone to take the time to merge comments. Ensuring accuracy from folks who aren't the primary authors will be hard, too. They might consider contributing unit tests, as well, which significantly raises the effort level required. I don't know if anyone would be interested.
Also, as far as I know, there's currently no formal notion of "the JBPM interface" - i.e., a restricted set of classes/methods that are intended for use outside the jar. Any contract/specification work would need to start with that definition of what is intended to be "truly public".
I don't have any idea whether the current committers would find any value in any of this. So far, no sign of it.
On the other hand... given where we are... for myself (and apparently for Ronald ;-)), I'd certainly appreciate it if you'd prune your technical queries by doing a bit more legwork. In the current case, the fact that a JbpmContext scopes transactions is documented in both user guide and javadocs, and could have been surmised by anyone with your experience - it's a common pattern.
First, the basic 'truly public' api is the JbpmContext, although it is not limited to that. On the one hand it blurs the line, on the other hand it gives advanced users the ability to go beyond basic usage.
Secondly, surprise surprise, I have committeraccess (although I rarely use it). I'm willing to merge any changes/enhancements/... to the documentation (manual or javadoc) that others make/propose into the codebase if:
- they are made against the latests version from cvs as possible
- these diffs are in a jira issue with a good description (more than one diff may go in there)
- they are not just dots, comma's etc.. butr real enhancements.
...the basic 'truly public' api is the JbpmContext...
Yeah, I suppose I'm trying to make black and white what's really grayscale.
I'm willing to merge any changes/enhancements...
I see your points. I just learn better top-down, starting with the intent of the code, then checking the implementation. Sometimes implementations have side effects that aren't relevant to the API, you need the designer's intent to really know what's important. I'm sorry if you feel it clutters up the forum. I guess I'm a minority of one. But potentially these threads could help others get up to speed faster, make jBPM more popular, yada.
I disagree the persistence behavior of JbpmContext is obvious. I think kuk's statement "opening a JbpmContext opens a session in a transaction if one is configured or already running" deserves some discussion.
Maybe we just need a separate forum for jBPM users who want to chew the fat about how it works as opposed to the more troubleshooting oriented inquiries. I might get lonely there though...
But please know -- I am reading my eyes off and doing my homework, there's just a heck of a lot to cover.
To discuss the future and current design issues, we have the design forum.
But in addition to this, I was thinking why you were worried about the deployment and not about all other methods that 'steer' the engine. Is that just because the .save(..) is hidden in the deployProcessDefinition method?
I disagree the persistence behavior of JbpmContext is obvious.
What, exactly, are you expecting that would make it obvious?
A search through the user guide for "transaction" will get you:
A JbpmContext typically represents one transaction.
The persistence service [exposed by JbpmContext] will obtain a jdbc connection and all the other services will use the same connection to perform their services. So all of you workflow operations are centralized into 1 transaction on A JDBC connection without the need for a transaction manager.
By default, jBPM will delegate transaction to hibernate and use the session per transaction pattern. jBPM will begin a hibernate transaction when a hibernate session is opened. This will happen the first time when a persistent operation is invoked on the jbpmContext. The transaction will be committed right before the hibernate session is closed. That will happen inside the jbpmContext.close().
Use jbpmContext.setRollbackOnly() to mark a transaction for rollback. In that case, the transaction will be rolled back right before the session is closed inside of the jbpmContext.close().
There are pages more on transaction handling. While I agree that the docs are weak in a lot of areas, you lose your right to gripe if you won't use what's there!
x: "God, please let me win the lottery. PLEASE let me win the lottery."
God: "Try buying a ticket?"
And the user responded: "But I did buy a ticket. I went to London and back by KLM, but I still didn't win the lottery"
I don't know whether to kill myself or go bowling.