Im am writing an application for the JBOSS JEE-Server. I would like to have the DB-access code quite robust. Thus I have created retry loops so that the request won't fail because of temporary network problems. Now I would like the execution of the request to pause in between retries.
The server thread has been spawned by a request to an Axis Web Service. Is it safe to put the server thread to sleep or will I have to spawn a thread of its own for this?
Yes you can put the thread to sleep using Thread.currentThread().sleep(XXX). But you should limit the number of tries otherwise in case of long network issue the thread will keep hanging for that long.
If what you are trying is to have a process reconnecting to the database in case the connection is lost, you are better off letting JBoss handle that for you, just define your datasource in JBoss and it will manage a connection pool for you, validating the connections and discarding the ones that are no longer valid so you always get a valid connection.
Trying to control the threading within your JBoss server will end up causing you more problems and quickly become a nightmare. JBoss already manages the database connections and transactions very well; so, unless your database is located somewhere outside your local network, it is unlikely your transaction will fail because of network outages. Also, adding in 'retry' logic to your business methods (ala session beans) is not really a good idea either as this would introduce long running transactions which would lead to transaction timeouts and entity locking issue - which puts you in the same boat as the less likely network outage.
Typically, you would catch any rollback errors on the client side and handle retries there. But, if you really need to introduce 'retry' behavior on the server side, I would recommend leveraging MessageDrivenBeans to perform those operations asynchronously. When a client calls a method on your session bean, instead of running the business logic, constructs and deliver a JMS Message to a local queue. This message would contain the name of the called method and a map of the parameters passed by the client. Listening on that queue would be a MDB that deconstructs the message to either perform the business logic directly, or make a call to a session bean to perform the logic. If there is a transaction rollback, then the message is pushed back onto the queue and redelivered to the MDB at a later time.
For JBoss 4.2.3 messaging, you can add the following properties to your JMS message to control the delivery time and how long JBoss should wait to redeliver a message after a failure:
JMS_JBOSS_SCHEDULED_DELIVERY - takes the delivery time in millisJMS_JBOSS_REDELIVERY_DELAY - number of millis to wait before redeliveryYou would add these values to the message before pushing them onto the queue - manipulating the delivered message from the MDB doesn't work. Also, be aware that if a message is delivered too many times (defaults to 10 times), then the message will be moved to the deal letter queue (DLQ).