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

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

by brittm

anonymous wrote : A 'good' practice is to not store domain data in your workflow engine and just store references. It is possible then (afaik) to use both frameworks (hibernate and iBatis) side by side then by using XA datasources... and a JTA transactionmanager. So the real need is not that high imo. | The issue with this (and for us its been a big issue) is the subsequent inability to update then read the same table row in one XA when the row is updated by one persistence mechanism and then a read attempt is made by the other. (This generates a deadlock in the DB.) Scenario: * A Business domain uses the container's JPA. jBPM uses Hibernate, so we're using two different persistence architectures. | * User completes a task via an application in the business domain. The action updates a series of domain objects based on data recorded from the screen and then calls a jBPM service to advance the process. | * A jBPM process executes and at some point needs to read data from one of the domain tables that were updated earlier. (A jBPM process may traverse multiple decision trees and launch multiple points of integration and/or child processes, so that it may be impractical to try to consider exactly what all might be part of this big XA transaction.) | * The database will deadlock since the original update to the table won't commit till the entire XA commits. However, the XA won't commit till the read is complete, and the read is waiting for the update to commit. | | If both domains were using the same persistence architecture (the same persistence unit), we'd be using the same JTA transaction and the same DB connection, and there would be no deadlock. | | This problem can be overcome in one of three ways that I can see: * Use a single persistence unit on a single server for both the domain and jBPM. | | * Enlist jBPM (Hibernate) in the same JTA transaction that was started via JPA. Anyone know how to readily do this? | | * Put the domain application and jBPM on separate servers, using a JMS (or similar) interface between the two. This ensures (mostly) that the domain transaction can complete ahead of any jBPM transaction and vice-versa. Of course, if your process does lots of back and forth with your domain objects, this is going to get pretty heavy pretty fast--don't forget to make provisions for rolling back each call. You had better be good at writing a solid framework to handle it, or you're going to lose your sanity. | | These solutions really reflect two simple strategies. When it comes to persistence, either get your domain and jBPM completely together, or keep them completely apart. Any in-between is a recipe for eventual trouble. Unfortunately, in its current incarnation, jBPM doesn't make either of these solutions readily available--you can't readily switch out the persistence mechanism, and jBPM doesn't provide a viable JMS interface. | | To date, we've been able to side-step, hurdle, or otherwise work around these deadlock issues as they arise, but it's truly been a mine field for the designer (me, in this case). Am I just missing something really simple here? | | Of course, the impetus to break out jBPM's persistence mechanism is lessened since future versions will be based on standard JPA, but the above concerns are applicable to anyone using the 3.x branch--which is basically every jBPM user at this point. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204088#4204088 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204088

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JTA/JTS thread disassociation semantics

by mark.little＠jboss.com

Yes well welcome to the world of presumed abort and checked transaction semantics. Although the OTS doesn't mandate them or which implementation you use, it assumes they're in place. (In fact we allow the terminator to be nulled-out to prevent this situation.) So realistically the status depends on the checking that's in place at runtime. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204061#4204061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204061

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by anil.saldhana＠jboss.com

"david.lloyd(a)jboss.com" wrote : But then, of course, the client servers need a password or key to access the central key server, which then brings you back to the original problem... Of course, it boils down to safeguarding private keys. I have not looked at solutions here (TPM, HSM etc). :) I was wondering why there was a need to inject DH Key Agreement internals as POJO, then seeing that you are planning to do SSH implementation - it made sense. One other area, where it makes sense is the implementation of WS-SX (Web Service Security Conversation). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204058#4204058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204058

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by david.lloyd＠jboss.com

But then, of course, the client servers need a password or key to access the central key server, which then brings you back to the original problem... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204048#4204048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204048

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by anil.saldhana＠jboss.com

"david.lloyd(a)jboss.com" wrote : Sure, I was just following the line of thought. A generalized password storage/injection mechanism is an interesting idea, similar in requirements to storing keys really. Anyway I'll have to have some solution to this problem to finish the SSH implementation... One possible solution is to centralize the keys in a key server that can be accessed by both the client and the server. They need to communicate to the key server via strong pki. JBoss XMLKey (as part of JBoss Identity) is the direction for this (preliminary but slow steady strides). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204045#4204045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204045

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by david.lloyd＠jboss.com

Sure, I was just following the line of thought. A generalized password storage/injection mechanism is an interesting idea, similar in requirements to storing keys really. Anyway I'll have to have some solution to this problem to finish the SSH implementation... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204043#4204043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204043

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by scott.stark＠jboss.org

You would need a password source bean to inject this from a configured source. The basic problem has no general solution, so you have to allow the users to configure how its bootstrapped. I don't see this as an impediment to working towards a general encryption capability. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204040#4204040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204040

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Some comments on Clebert's last commit

by clebert.suconic＠jboss.com

"Tim Fox" wrote : 1) Forcing depage. I don't get this. Looking at the code I can see you force a depage if the reference isn't found in the queue | | a) I notice you only force one depage - How can you be sure the required message is in the next page? It might be in any page after that. | | b) Let's say you force a depage and the message *is* in there, the message will get depaged and routed to the queue. I can't see anywhere where the reference is then removed from the queue. Could this lead to duplicate deliveries? | There's a loop there: for (;;) // I'm changing this for while(true) | { | // Can't have the same store being depaged in more than one thread | synchronized (store) | { | // as soon as it gets the lock, it needs to verify if another thread couldn't find the reference | ref = messageQueue.removeReferenceWithID(id); | if (ref == null) | { | // force a depage | if (!store.readPage()) | { | break; | } | } | else | { | break; | } | } | } | And on the backup, that's the only time we depage until it is activated "timfox" wrote : | 2) Address is being passed on replicate delivery mesage. This worries me for performance reasons. Can't we do this another way? | I have removed it here locally. I'll use the messageQueue.getName() :-) "timfox" wrote : | 3) Precalculation of flow control | | a) if ((creditsUsed -= chunk.getRequiredBufferSize()) < 0) | | Looks suspicious - this will actually decrement the creditsUsed variable | | I'm renaming this variable to precalculateAvailableCredits. We take the credits in advance from the preCalculateFlowControl, and I keep sending while I have precalculateAvailableCredits "timfox" wrote : | | b) Can you be sure that the first large message chunk gets sent iirespective or available credits? - we need to ensure this to avoid blocking | I will take a look, but how this would avoid blocking? "Tim Fox" wrote : | c) pre-calculation of credits seems very complex... looks like it could do with some optimisation I don't know... All the equations I tried had an indefinition where I would need a loop series to solve it. I will try to think a little bit more. "Tim Fox" wrote : | | MultiThreadRandomFailoverTest is running a lot slower | | I just did a comparisson before and after my commit, and it ran the same. However the test runs much slower on Hudson. Maybe there is a VM on the non-vm queue by accident? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204039#4204039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204039

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Security services deployer for the MC

by david.lloyd＠jboss.com

The classic problem with encrypting values is that somewhere - somehow - you have to store or acquire the secret/private key or password so that the server can decrypt the value. For a server starting up, it's hard to imagine a place that a key/password could be stored that would be more secure than where its regular configuration could be stored. While this module would definitely make it easer, in some ways, to get the tools needed to perform the encryption/decryption, it does nothing to solve this basic problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204037#4204037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204037

17 years, 2 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: JTA/JTS thread disassociation semantics

by jhalliday

I'm not arguing with the ORB's behavour, I'm arguing about the way the transaction service sat on top of the ORB translates that. If a client gets an OBJECT_NOT_EXIST it only knows the tx went away, not what state the tx was in. Assuming rollback is unreasonable - it may just as easily have committed via another thread or a different JVM. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204030#4204030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204030

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