11. juni 2006 - 09:38Der er
14 kommentarer og 1 løsning
Delicate concurrency access problem
Hello!
I have a problem with tow apps that is accessing the same object in a database.
Short description is that app 1 creates the object a triggers fires and app 2 should read the object from the database. How ever the trigger fires to quick and the object may not have been stored to the database when app 2 is accessing it. I guess you see the problem.
Long description app 1 is running in a weblogic and posts a JMS-message on a OpenJMS queue (we do not have license for JMS in our weblogic). This happens when a object is created. Unfortunately this is not an ordinary database so we can not use SQL and ordinary triggers. I guess the implementation works alot like Hibernate. Then I guess the trigger fires when the object is created in the RAM and not in the underlaying database that is in this case an Oracle database (but we can not get hand on the oracle at all).
When the triger fires app 1 posts the JMS-message that is in indication two app 2that it should read this newly created object and do some stuff. This app 2 is running in a TomCat.
When app 2 is accessing the database the object is not created and stored yet.
If we could use Weblogic there is a "Time To Deliver Override" to set on the topic that app posts to but I guess there is nothing like this in OpenJMS.
Perhaps the only solution for this is that app 2 when it gets a message it instances a threaded app that waits for a couple of secs before it proceed?
Den moderne arbejdsplads er i stigende grad afhængig af mødelokaler til at fremme samarbejde, men dette skift medfører også stigende sikkerhedsudfordringer.
Unfortunately I'm not able to tell how exactly app 1 is saving the data. I only guess that nit looks like it takes some time like 1 sec or 2. So my aim is to delay the app 2 when it gets notified about it. So if ypou got ant ideas how to delay app 1 in the best way. Please let me know.
I guess you think a delay does not sound very safe, neither do I. But it looks like this will solve the problem.
Maybe (just maybe) it would be an option to put a transaction manager in your Tomcat, integrate that with your message queue and simply rollback if you are not ready
Perhaps I'm a bit offside regarding to your comment: I thougth you already had a listener thread to read from the queue
Correct me if I'm wrong if I say that if I instantiate my listener from a servlet during init of that servlet. Then I have a own thread for this listener together with that servlet? If I then run Thread.sleep(5000) from inside the listener I will stop this Thread for 5 sec? Since this is the only thing I have in this app, I may have been sloppy saying that the whole app will stop. Or have I missunderstand how a servlet is running in a thread of there own?
How ever what you said about a transaction manager I guess this must be the correct thing to do. Unfortunately I do not know so much about this but there rings a bell about JTA. If you got any hints I where to start I would appreciate it a lot.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
