Skip to main content

WSTX-AT-0022: Registration with durable parent failed:

3 replies [Last post]
abll
Offline
Joined: 2008-12-30

Help, I am trying to make a simple http web services call from one glassfish container to another with EJBs exposed as web services. I get a message indicating "SOAPFaultException: WSTX-AT-0022: Registration with durable parent failed". The SOAPFault also includes a javax.net.ssl.SSLHandshakeException because the 2 servers (on different boxes) do not have SSL certificates set up withCAs.

I understand the wsit transaction is trying to use SSL for the transaction manager but I really don't want the transaction and don't want to set up SSL between the 2 servers since it is not required for any other reason.

My client is executed from an EJB Timer. I have modified the TransactionAttribute on the EJB methods to be TransactionAttributeType.NOT_SUPPORTED per the following thread:
http://forums.java.net/jive/thread.jspa?messageID=364573.

For some reason it still has it in a transaction. I can make the http WS call from SOAPUI no problem.

Any ideas on how to force it not to use the transaction from the client? Shouldn't the TransactionAttributeType.NOT_SUPPORTED cause it to skip the wsit transaction?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
abll
Offline
Joined: 2008-12-30

Ok, the problem appears to be related to the execution from the ejb timer. If I execute by making the ejb call directly from a client app the call is not in a transaction and the web service call succeeds. When it is called from the timer it fails.

I have marked all the methods in my timer and ejb with the TransactionAttributeType.NOT_SUPPORTED but it still seems to put it in a transaction and the web service call fails with the WSTX error.

Is there any way to force the timer to not use a transaction?

Marina Vatkina

EJB timer itself because it's persistent by definition, is implemented as an EJB
with persistent support (CMP prior to v3, and as a SLSB with JPA backing in v3).
So this explains the transaction appearance in your test.

But how does it affect the rest of your app? EJB timer bean accesses its own
(XA) database, if you didn't change anything.

thanks,
-marina

glassfish@javadesktop.org wrote:
> Ok, the problem appears to be related to the execution from the ejb timer. If I execute by making the ejb call directly from a client app the call is not in a transaction and the web service call succeeds. When it is called from the timer it fails.
>
> I have marked all the methods in my timer and ejb with the TransactionAttributeType.NOT_SUPPORTED but it still seems to put it in a transaction and the web service call fails with the WSTX error.
>
> Is there any way to force the timer to not use a transaction?
> [Message sent by forum member 'abll' (jodendahl@tandbergtv.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=367677
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

abll
Offline
Joined: 2008-12-30

Hi Marina, thanks.

It is affecting my application because from the ejb timer I am making a web services call to another glassfish server. Since it is in a transaction glassfish automatically initiates a wsit/wstx transaction and attempts to make an ssl connection back to my (client) server. This ssl connection fails because the certificates are not set up.

The solution I found is to move the web services call to another slsb that has the TransactionAttributeType.NOT_SUPPORTED. So the ejb timer makes a local slsb call to a non-transaction method which then makes the http WS call.

This seems to work.

thanks