Re: [cdi-dev] Transaction Scope for CDI

Responses in-line... [mailto:cdi-dev-bounces@lists.jboss.org] you [Reza Rahman] That's fair and something I anticipated. The problem is that it would be a bit odd to discuss all the supporting use-cases in the spec itself since the others do not. We can certainly do that here (to a great degree Nigel, I and Pete already have) and maybe add to the spec if we deem it necessary. NormalScoped [Reza Rahman] Can you kindly elaborate? As such, JTA does not allow nested transactions. What it does allow is one or more suspended transactions in the same call-stack. In case of CMT, this would be a non-issue since the contextual objects would not be propagated beyond method invocation boundaries. In case of BMT, you really can't suspend the transaction, so this would work there as well? get right [Reza Rahman] Could you be more specific? That would be helpful in making this more concrete. [Reza Rahman] If a significant portion of this EG feels this way, we can certainly get this clarified by Bill, Linda, et al. My suspicion is that although this might not be the ideal place, it is likely the most pragmatic place. Either way, it would be good to vet out the technical aspects of the proposal with CDI centric folks. parts, the [Reza Rahman] Hmm - not sure what you mean? Could you kindly propose alternate text? If anything I felt I was writing too little... invocation ==false [Reza Rahman] I avoided calling out specific CMT cases to keep this compact. The use-case is handled though if you trace it through. In the REQUIRES_NEW case, if there is an existing transaction, it would be suspended and hence any contextual instances that belong to it would not be propagated past the new method invocation. If there wasn't an existing transaction, the case would be relatively straight-forward -- the instance would be created and placed into the transactional cache. In addition, it will propagated to the end of the method call to handle the BMT/short-transaction use-case. Actually [Reza Rahman] It is true that this is deliberately focused on JTA. The basic reason for this is ease of standardization since the JTA semantics are known. If the JTA case can be standardized, I imagine one could tackle the case of other transaction management APIs down the line if theirs APIs are also adequately standardized as far as CDI/Java EE is concerned. Also, personally I am a supporter of JTA and see few technical reasons to avoid it's use. Nevertheless, I deliberately tried to keep that possibility open (not the parenthetical remark about CMT/BMT==JTA). defined [Reza Rahman] Again, could you kindly propose specific alternate text? That would be greatly helpful. [Reza Rahman] Not sure I follow? The way it is specified, the object would be created and propagated across the method call. Any transactions that become active after the object is created can still be utilized by the instance? Context#isActive() [Reza Rahman] Right. This was the initial implementation/concept in Resin. The trouble is that it is severely limiting for BMT and cases where there is no active transaction. For example, the JPA entity manager can be used outside of an active transaction as long as you stick to "read-only" methods: . The case in the JMS context is even broader since you can use the JMS APIs without a transaction (even within Java EE). [Reza Rahman] Not sure what you mean? Limiting propagation to method boundaries was specifically designed to avoid sticky situations where transactions may be suspended/activated on the same thread multiple times. EJB- [Reza Rahman] Right, but the point is that CMT transactions can and do indeed span multiple method calls (e.g. is transaction propagation is set to REQUIRED or SUPPORTS). In such a case, the context would ensure that all methods in a the call-stack participating in the transaction are referring to the same instance. JSF invocations, [Reza Rahman] Yes, propagating instances across the transaction would handle this the way it is described now. BTW, for JPA in particular, you are actually not allowed to propagate EMS from stateful to stateless contexts: http://docs.jboss.org/hibernate/entitymanager/3.5/reference/en/html/architec ture.html (not a reasonable restriction IMO). to get [Reza Rahman] Right -- I fully expect that and is the reason I will likely need to tend to this discussion for a duration (which is fine). The issues you raised are good conversation starters. Alternatively, we could start with a bunch of use-cases and see how the proposal fits? Luckily, we do already have those for the proposed JMS 2 context (maybe Nigel can oblige here?). Also, I could pose some pseudo-code for the proposal (tends to be easier to follow since it provides conditional structures which natural language does not). I do think this is an invaluable feature for starting to integrate transactional/JCA aware resources in a meaningful way via CDI. we might your