I'll try to answer your questions below:
Davide Mora wrote:
> Hi,
>
> i read some former emails about client demarcated
> transactions, expecially mails between Dan OConnor
> and Stuart Barlow named "UserTransaction problems",
> but i still have some doubts about this topic.
>
> 1- Is not required by ejb spec. to give access to
> transactions from the client. I'm right?
Right, the EJB 1.1 spec explicitly states that one need not provide
UserTransaction object to just any client, though clients running within
the EJB server should have access to it.
>
>
> 2- UserTransactions are not currently supported by
> jBoss, rigth?
That is correct. It's being actively worked on though.
>
>
> 3- If i use an ejb server that support transactions at
> client side, my ejbs/clients will be portable between
> application servers that support this feature?
Sort of. It depends on how you look up the UserTransaction object. The
J2EE specification says you should use "java:/comp/UserTransaction," but
I know of at least one app server (JoNaS) that DOES support client
UserTransactions, but uses a nonstandard way of looking it up.
>
>
> 4- If and when client demarcated transactions will be
> available for jBoss?
Yes they will be available, at least for clients running in the jBoss
VM. For instance, we have a goal to provide client-demarcated
transactions to Tomcat servlets if you use the Tomcat integration
feature of jBoss. As far as when, that's more of a gray area. The
transaction system needs a good deal of work...it needs to support
distributed transactions (which it does not), and it needs some
restructuring to effectively support client-demarcated transactions.
I'd like to implement all this myself, but I am still learning my way
around jBoss, and I don't have just a whole lot of time to devote. I'll
help where I can.
>
> 5- Where i can find more details/example about the
> "facade pattern with a stateless session bean"
> approach suggested by Dan OConnor?
I'm not EXACTLY sure what you are talking about, but I think I can make
a good guess. For maximum portability, you should let the container
manage as much as possible. You can achieve the equivalent of
client-demarcated transactions by using container-managed transactions
(CMT), and using a stateless session bean as a proxy for your client.
The client calls a stateless session bean method with the Required
transaction attribute. That stateless bean in turn calls all the
methods you want to call in a transaction. For just any client (i.e.,
not one running within the app server), this is literally the ONLY way
to ensure client portability.
>
>
> Thank you,
> Davide
>
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
