• Post Reply Bookmark Topic Watch Topic
  • New Topic

Consequences to a bean in process when connectivity with App Server is lost!!  RSS feed

 
aanchal mathur
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
We are currently developin a financial solution which involves alot of transactions like paying of bills. Now the problem being faced is if in between a transaction,due to the network shut down or similar reason, the client Machine looses connectivity with the APP Server, then that current transaction comes to a compelete standstill,thus causing the application to stop.Due to this it can happen that half the data is entered in to the databsae and due to suden breakdown the other half cannot be entered,thus resulting in the entire transaction to be started all over again. We have craeted a cache on the client side which stores teh database in an xml format.But the problem is if the APP server is down, then none of the EJB's can be accessed which allow all of the busines process to be completed. So then how do we make sure that even if in standalone mode the client machine can follow up with a transaction (which requires business methods) and store whatever result we get to a message queue which later updates the database when connectivity is got.
Its not possible to have the EJB;'s on the client side so can anyone pleasee suggest a solution!!!
 
Phil Sharp
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think there is any easy solution to your problem. The solution will be dependent upon your particular application.
Some thoughts that might consider:
1. Main thing to do is minimise the chance of failure, use clustering etc.
2. If it is only network failures you want to protect against can look at using Handle and HomeHandles to keep references to EJBs. Will not work if the app server crashes which is probably more likely than a network failure.
3. Use a session facade pattern, allowing the logic to happen in the app server. Then you can pass all the infromation in one go which makes it easier to control the transaction.
4. If you really want resiliance think about using JMS. If you are using EJB2.0 can partner this with message driven beans.
Hope the ideas are of some use.
Phil
 
aanchal mathur
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
Thanx alot for ur reply.definately it has helped me to quite an extent.Now i can atleast handle the network failure part,but that was just as an example..what i was stressing was on failure of App Server.So i guess i found ur suggestion of using Message driven beans as the best solution .

Hi Again,
After doing a little R&D on JMS, Message Driven Beans etc,I realised that we are firstly making use of EJB1.0..so there is no question of using Message driven beans.And anyways even Message driven beans are called either via session or entity beans. Now even if we make use of JMS, it requires a
Java Naming and Directory Interface (JNDI) lookup of the QueueConnectionFactory and queue .
What i want is if the APP server completely shuts down,due to whatever a crash, netwok failure, none of the beans be it session or entity or message beans will be accessible to the client m/c . So does IT mean that till the application server doesnt start functioning , the client cannot access any business methods,which means the application comes to a total standstill or is there some way that the client m/c can do the business processing and store whatever results it gets to the JMS service ???

[This message has been edited by aanchal mathur (edited November 26, 2001).]
[This message has been edited by aanchal mathur (edited November 26, 2001).]
 
Phil Sharp
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aanchal
As far as message driven beans are concerned they are not instantiated by session\entity beans. They are instantiated by the EJB container and listen to the JMS queue (or topic), once a message is on a queue the bean gets it and processes it. Message-driven beans can call session\entity beans but not vice versa - they do not have home, remote or local interfaces.
The messaging service can be setup to persist messages or not. If it persists a message it stores it to a datastore and if there is a failure it is still available on recovery. Need to investigate the app server\messaging service to see how this is implemented.
You are quite correct about the JNDI and QueueConnectionFactory - if the app server is down and it is providing the JNDI/messaging service you cannot access it.
What application server are you using? Check whether and how it supports clustering? Basically clustering involves having the EJBs\message queues\JNDI replicated on multiple instances of the application server linked together, then if you lose one, another takes over.
Also I'd recommend you look at your transaction control. Basically you want it to be an all or nothing approach as regards processing, as then its easier to recover.
Good luck
Phil
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!