legolas wood wrote:
> Hi Sean, Thank you for your extended reply.
> Our client can be
> -A Servlet in the same application server that our web services resides.
> -An standalone simple command line client in the remote machines.
> We have option to use one of this as controller to call those two web
> services. I can not change the design and put both operation in the same
> web service endpoint.
> So, using one endpoint to handle transaction issue is not a solution
> for us.
> You have mentioned WS-* like WS-TX and other standards, can you please
> let me know where i can find information about using glassfish and this
> standards?
There is a tutorial sample available at
https://wsit-docs.dev.java.net/releases/m3/AtomicTransactions.html#wp100322.
The sample illustrates a client as a servlet calling a transacted web
service implemented as a servlet or EJB.
Since WSTX is fully integrated with Java EE transactions, you can also
make updates to a XATransaction enabled
resource in the servlet or make calls to transacted EJB methods and all
transacted resources will be committed or
rolled back.
The following Javaone 2006 presentation gives an overview of the WSTX
capability.
http://developers.sun.com/learning/javaoneonline/2006/coreenterprise/TS-1603.pdf.
See slides 20-30.
-Joe Fialli, Sun Microsystems
>
>
> Thanks.
>
>
>
>
>
>
> glassfish_at_javadesktop.org wrote:
>> Hi,
>>
>> Once clarification, when you say "client", what do you mean? Is
>> client a broswer or swing app? Is the client another server-side
>> application that wants to call two web services that are part of
>> another glassfish application? Or is the client a Servlet or another
>> Java EE component within the same application as the web services? Or
>> what?
>>
>> Generally, UserTransaction is not used across client calls if the
>> client is a browser or swing app etc, as it is not really meant to
>> have a client make a call to server and start a transaction & do some
>> stuff and return to client, then have client make another request to
>> server and do some more stuff, then close/commit transaction and
>> return to client again. This is something that people mistakenly try
>> to do in web browser web apps too. In these cases you should not
>> leave the transaction open. Each web request from the client should
>> have its own transaction.
>>
>> Can you reconsider changing your application design to have a single
>> webservice endpoint, and that endpoint code starts a UserTransaction
>> and then accesses the DB and then access the JMS resource, and then
>> ends that transaction? That is the more typical use that
>> UserTransaction is intended for, which is a component running in Java
>> EE app starts a transaction and then access one or more transactional
>> resources(DBs or JMS queues etc).
>> Generally with SOAP web services the transactional info is not
>> propogated along when you make several calls to other services. The
>> support to pass all the info along is just not there in SOAP web
>> services. This type of support to pass along the transactional
>> context among calls is part of RMI-IIOP so you can get this behavior
>> for example if you have an EJB component call another EJB component
>> using RMI-IIOP.
>>
>> Propogation of the transaction context and other info for web
>> services is functionality that is added to web service through some
>> of the other WS-* specs. But its not part of the core web services
>> standards like SOAP.
>> hth,
>> Sean
>> [Message sent by forum member 'sean_brydon' (sean_brydon)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=213058
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>