Details
Critical Description
Dear sirs,
in order to test our calculation engine, that runs inside a EJB
container (as an MDB for batch processing), we decided to use
CDI to test this calculation engine .... outside of the JEE
container, within a looping Junit test.
The JUnit test invocation (and mocking) is working well with
DeltaSPIKE and Weld-1.1.10. That's perfect.
Unfortunately we are unable to run the calculation engine
inside the EJB-container (respective as an mdb), cause the
XA-datasource went mad and logged out weired messages of
unsucceeded connect-request or weired transaction context.
So i decided to extend my maven-driven test application,
in order to emulate that faulty behaviour. This application
works similar to our application.
Small test app description:
The major project contains three sub-projects:
+ CdiTestMackEAR for to build the ear
+ CdiTestMackEJB contains the EJB beans
ok, there is actually ony one, that (self) initiates
our test by means of a timer, that is attached to
the timelyTest runner.
+ CdiTestMackService sub package that contains the calc engine,
that is implementet in the CalculationEngineExmp01Impl
class. Any data request is beeing declared by the
DataSvcIf interface.
Implementation are
- MockMeMockMe for JUnit testing and
- JpaDataSvc the failing JPA implementation.
You can simply let the application write a bunch of
exception, iff (see ServiceAccessPointBean.java line 55ff
assign a string:
inParamter.setBoxName(myBoxName) ;
or blind out any exception:
inParamter.setBoxName(null) ;
Finally both assignments cause problems, but apparently the
first one creates excptions.
Conclusion:
1) From my point of view the cause of the problem is
the CDI-API, that lacks of some important functionality
for transaction oriented processing.
When the transactional method starts to run,
the SLSB has been activated (postconstruct finished).
All my ressouces have been reserved for my atomic
operations. I will not require additional ressources
from the injected implementation during runtime.
Therefore all injected references should have been
initialized (with their ressources) or better should
be re-use the reserved/allocated ressources.
In other words: Iff my atomic transaction starts,
i do not want to allocate others during runtime.
(we are not playing the Spring game in an EJB!!!)
As a consequence of this, i would expect a
passthrough interface, sharing my reserved
ressources to the injected instances.
Besides, it should be possible (better say the standard),
to inherit the current transaction context to the
injected implementations, maybe some of them
needs them. (Nestated transaction shall not be
the only one option).
I was thinking of the transacion-cts, when i was
folling the irritating stack traces. I guessed, that
each CDI invocation created a separate transaction
context outside of the EBJ container.
Iff you have any question, let me know.
For now, i'll have to remove the CDI from
our project, until it is transaction safe.
(SEE ALSO: http://stackoverflow.com/questions/8772175/how-to-implement-container-managed-transaction-cmt)
Another thing is: Please write in your documentation
what can be doen with Weld/CDI and which use cases
(like mine) is not expected to work.
