I am creating a web application. Same application will run from different machine, but
they will use common database. When application starts it will get all data from database.
But when I update data from one application, how other running application will know that data
has been updated, I want when I update database form any application, other running
application will get notification immediately, and they should update their data.
One possible solution is I can take all applications URL in a list, then after updating value
I will send request to all application, but how to do this using send Redirect. Is it correct way ? or is their any other easiest way to do this. Please help me.
Is it a requirement that data is loaded once on startup? If it's not than you can just read directly from the database with a low cache invalidation time.
In case your apps need to be synchronized "almost immediately" I would do it like this:
You can set up a messaging server which would create a JMS topic. All of the clients will listen to messages from that topic. When one of the apps update something in the DB it will send a message to the topic. The rest of the apps will get the message and update.
Related
I am new to database and i am working on an application which has a gigaspace based cache and the backend data is a sybase database.
Unfortunately there are a lot of places from where the DB gets updated via stored procs. Hence i would like to have a way via which i can get notifications whenever my DB is updated.
After doing some research i found that sybase does has the ability to send out events to Tibco EMS but unfortunately it requires separate license.
Is there any other reliable way i can get table update notifications without using a messaging system like may be some kind of rest ?
You can send a message to a UDP port using syb_sendmsg(); this requires some configuration settings but no license. Note that UDP is not as reliable as TCP.
If you don't want to use any more licensed options you could make a trigger on the table and put code in the trigger that would send data to JMS.
Or it can call some custom Java class (Java in database) that could do virtually anything.
Another options i to use XP server and call some external program that would populate the cache or JMS queue.
This question might sound a bit abstract,answered (but did my search didn't stumble on a convenient answer) or not specific at all ,but I will try to provide as much information as I can.
I am building a mobile application which will gather and send sensory data to a remote server. The remote server will collect all these data in a mySQL database and make computations (not the mysql database ,another process/program) . What I wanna know is :
After some updates in the database , is it doable to send a response from a RESTful Server to a certain client (the one who like did the last update probably) ,using something like "a background thread"? Or this should be done via socket connection through server-client response?
Some remarks:
I am using javaEE, Spring MVC with hibernate and tomcat (cause I am familiar with the environment though in a more asynchronous manner).
I thought this would be a convenient way because the SQL schema is not much complicated and security and authentication issues are not needed (it's a prototype).
Also there is a front-end webpage that will have to visualize these data, so such a back-end system would look like a good option for getting the job done fast.
Lastly I saw this solution :
Is there a way to 'listen' for a database event and update a page in real time?
My issue is that besides the page I wanna update the client's side with messages from the RESTful server.
If all these above are unecessary and a more simple client-server application will prove better and less complex please be welcome to inform me.
Thank you in advance.
Generally you should upload your data to a resource on the server (e.g. POST /widgets and the server should immediately return with a 201 Created or (if creation is too slow and needs to happen later) 202 Accepted status. There are several approaches after that happens, each has their merits:
Polling - The server's response includes a location field which the client can then proceed to poll until a change happens (e.g. check for an update every second). This is the easiest approach and quite efficient if you use HTTP caching effectively and the average number of checks is relatively low.
Push notification - Server sends a push notification when the change happens, report's generated, etc. Obviously this requires you to store the client's details and their notification requirements. This is probably the cleanest approach and also easy to scale. In the case of Android (also iOS) you have free push notifications available via Google Cloud Messaging.
Set up a persistent connection between client and server, e.g. using a Websocket or low-level TCP connection. This should yield the fastest response times, but will probably be a drain on phone battery, harder to scale on the server, and more complex to code.
i am going to integrate some applications using RabbitMQ. Now i am facing the design issue. Right now i am having one application producing message and one application consuming it (in future more are possible). Both applications have access to some database. Application A is some kind of registration application when it receives registration request it sends message to on rabitmq. Now application b receives this message and its task is to load the registration data to elasticsearch server. Now i have some options
consumer will read the message and id from q and load the data and send it to the elastic search server
fastest throughput. Because things will move in asynchronous way. other process which may be running on separate
server will loading the data and sending to elastic server
consumer will read the message and id from the q and then call the rest service to load the company data.
will take more time for processing each request as it will be having network overhead.although it will save time to data load
but will add network delay. And it will by pass the ESB(Message Broker) also. (i personally think if i am using esb in my application
it is not necessary that i use it for every single method call)
send all the registration data in the message. consumer will receive it and just upload it to elasticsearch server.
which approach i should follow?
Apparently there are many components to your application set up that is hard to take into account and suggest a straightforward answer. I would suggest that you should look into each design and identify I/O points, calls over the network and data volume exchanged over the network. Then depending on the load you expect and the volume of data you expect to store over time I would suggest you hierarchize these bottlenecks giving a higher score depending on the severity of it. Identify the one solution that has the lowest score and go with that.
I would suggest you should benchmark the difference between sending only the iq or sending the whole object. I would expect that the difference is negligible.
One suggestion. Make your objects immutable. It is not directly relevant with what you are describing but in situations like yours, where components are operating "blindly" you will find that knowing that an object has not changed state is a big assurance.
The following programs exist:
1. I have a java application which accepts bio potential data every second or two and stores it in the database. This is a socket server which accepts this data from multiple clients and spawns a new thread for processing it to store in the db.
2. I have a jsp page on tomcat server which reads historic client data from database (stored by application 1) and displays it on the page.
The socket server program in 1.) above is not running inside of tomcat server.
The new requirement now is : Display all of the human data coming in live on the jsp page.
Now the problem:
I will now need to pass the live data from socket server (which is stand alone) to the jsp which is running on a tomcat server.
Possible solutions:
APPROACH 1: Run the socket server in the tomcat instead of stand alone and store the frequently incoming data in a java object so the jsp can access this object every second and display it on a graph.
PROBLEM : The stand alone java application does not need to be included in a tomcat server except for the fact that the jsp needs access to the live data. Also, I have read that this is not the best way.
APPROACH 2: Expose the stand alone java application as a web service and communicate with the jsp using REST architecture.
PROBLEM : The complication of using this method is that it will not have the flexibility offered by websockets or server sent events (SSE) of auto updating the latest data. The jsp will have to keep polling for new data every one second which is also not a very good option.
I need suggestions on which is a better method for accomplishing my task. Or is there a third better way which I have completely missed.
I have a java application which accepts bio potential data every
second or two and stores it in the database
You already have the answer: just display required data from this database in your jsp page. This will be easiest solution.
I undestand that you're trying to display realtime data, but JSP itself is not designed for realtime output, you will have the delay anyway and because you already have required data in database - no need to transport it to Tomcat server.
I have a system which contains the data of the employee and this system has exposed many web-services and RMI through which any other system can request for data. Now I have a web application hosted on JBOSS. Here the problem is, now I want to get the data from the system to JBOSS in real-time fashion. Though that system has sevral webservice and RMI services through which JBOSS/web-applications can request data but that is on-demand. I looking for a way thorugh which if there is any change in the system, JBOSS get notify at that moment. One solution to it is, I should make process which will call the webservice to know if there is any change in the employee data within a time-interval. What is the other way to notify the JBOSS in real-time?
One way is to have a job/separate process which polls your employee application periodically, and sends "data has changed events" to JBoss using JMS.
In JBoss you could have a message driven bean (MDB) whichs listens to these events, and stores them in a database.
Another possibility is to have this job running in JBoss which just stores the events/results in memory (search for Quartz, for example have a look at this tutorial).