Oct 19th, 2008, 04:16 AM
I haven't understood your architecture yet. You have a batch job which delegates to an SLSB, which in turn calls a legacy remote EJB? I wouldn't want to count on the remote call belonging to the same transaction as the caller at all in that situation, unless it is optimised into a local call by the container. (Websphere has a monopoly on remote transactions over RMI if I recall correctly, so the container might also save you in the opposite case.) Anyway, maybe you can check the legacy EJB, and if it is deployed with CMT then try and get it re-deployed locally with BMT? Or else make sure that it is idempotent, then you don't really care if it isn't part of the same transaction as your batch job started. I don't think the fact that you are launching a job from a Seam application is relevant as far as Spring Batch is concerned - we just need a normal Spring PlatformTransactionManager, and you should be able to provide one of those quite easily.
Oct 19th, 2008, 08:22 AM
Oh the reason i mentioned Seam was that with Seam's built in spring integration i could have given you the transaction manager used by the Seam bean thus problem solved.
Yeah i'll recheck the Remote EJBs, right now the push at our company is actually to make them all web services (since C++ apps may also need to interact with them) As far as deploying it locally depending on the service that may be a possibility ... i am not sure if it's my groups code or not though.
Thanks for oyur help .... i did quite a bit with Spring in the 2.0milestone phases .... but then switched to a company that was sticking with 1.2.