I am working on primefaces datatable which has data from the database. This client side data is received when the refresh button is hit. If there is a database change, the client doesn't know about it and has to refresh the page often.
I was looking for server side push technology and getting to know about WebSocket. However, I cant find or do not know how it will work in my situation.
The database change is done through Hibernate. So how do I monitor the database change done by hibernate? and, after detection send that value to the client?
I am using Java and tomcat.
since you're using primefaces, you can use the p:poll widget to monitor the server side.
OR
you could leverage the primefaces support for atmosphere.
if you're just monitoring a small amount of changes, a poller would probably be the easier solution. if you need to provide reactivity to a large number of changes, the pf-push and atmosphere framework will give you a good base to leverage.
Related
So I have a REST api. I want to keep it stateless, but at the sametime I need to make a real time chat.
The only way I can imagine a real time chat, is with websockets. The problem accurs that websockets, to my knowledge, seems pretty statefull.
Is there another way to create a real time chat?
My stack is Spring boot (java)
React frontend
Mongodb for database.
Plan for hosting would be AWS
And normally I would just ignore the 100% stateless or statefull, but this is for a school project, and I would look good in my report, to say I am 100% stateless.
the correct way achieving real time chats beside websockets would be to use firebase which is very common since usually the clients connected to your server will use android/iOS.
obviously an app connected to firebase is maintaining a stateful connection to firebase.
in general i dont think it is possible to provide push functionalities without state , as the server must reach the connected clients thus it must maintain those connections. if not using firebase, using websocket seems a reasonable approach.
I know two ways of implementation this. Easiest - websockets. Hardest - backend is calling frontend.
More about second solution. In normal world, we are calling backend using frontend, here will be visa versa. When backend will receive a message (from another user), it will tell frontend that message was received ant it should show it.
i'm planning on creating a system that has 2 parts, the first part will be found in the client side while the other part is in the server side. there are 2 different programs here running, the client side will save a data in the database and raise a flag or a trigger which will then be the cause for the server side part to start and retrieve data from the database and process it in an API.
at first i decided on using a scheduler on the server side to continuously run the program and check for any changes in the database using a "status" field, but then this is not that efficient as it would be wasteful to always check for changes.
thus i was hoping you can help me out in finding a different solution to my problem here so that i may do this more efficiently
You can use database triggers, upon a change in your db you can call a server side method embedded in a jar file.
The following link might help.
https://dba.stackexchange.com/questions/39522/execution-of-a-java-program-by-a-trigger
Update :
You can use asynchronous messaging services like jms which would work on publish & publish service, you would need a broker server for this is this way more efficient & elegant :)
For start you can follow to the guide from spring: "React.js and Spring Data REST"
https://spring.io/guides/tutorials/react-and-spring-data-rest/
Here Spring Data Rest on Back-end side with events(4th part of guide, right what you need 'from the box') and ReactJs as Front-end client.
If you are new in ReactJs it won't be a problem, you can follow guide from scratch.
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.
How can I have a push mechanism within a JSF Java EE App?
I have several backend values, that may sometimes change every other second, sometime every other minute, sometimes only one time per hour.
I do not want to do pulling on that variable, as this will be expensive when several clients connect to that page.
So I somehow need a push mechanism to only update the values on frontend if they are changed. Does anyone know how I could do this?
You can use Primefaces Push
PrimePush, powered by the great Atmosphere Framework.
Here some ref's :
PrimeFaces Push Unleashed
PrimePush
User's Guide 3.4
You can use RichFaces a4j:push. The client creates a permanent connection to the server either by using a WebSocket connection or the long-polling method. Permanent connections are managed by the Atmosphere Framework.
Push can be controlled by a programmatic API (Topic), or using CDI Events (#Push). Code is pretty lean.
I'm starting to develop what should become a client-server Application using Hibernate, Spring and Eclipse RCP (for the client). This is the first time I'm designing an application from the beginning so I'm just making my first steps.
I have set up Spring on both client and server using RMI for remoting (but I wouldn't mind using something else if there was a clear advantage). So right now I'm able to call exposed services of the server from different clients to get information from the database. What I haven't done is get any kind of authentication in place, so basically the server just answers to the different clients without knowing anything about them, there is not concept of a session yet. Of course this has to change since I need different user to have different roll and so on, but right now the problem I'm facing is getting the server to notify the client when certain thing happen.
My idea to solve this problem was to have a queue of events at the Server and have the clients get them every 3 second or so. The server would then identify the client by it's session token and send the appropriate events. Yet my partner in this project is concerned that this technique (polling) might waste too much bandwidth unnecessarily.
So to bring it to the point. What are the standard techniques for a server to notify a client about changes using Spring? Please notice that I'm not developing a web application and that this is only intended to be used withing a private network. That is one of the difficulties I've been facing: every single tutorial about Spring security or remoting assumes you are making a web application, but I really don't want to get lost into the details of Spring MVC and web applications in general.
Any resources would be appreciated. A good and long tutorial on the matter would be great.
EDIT: Hmm, it looks like JMS might be what I'm looking for.
As I understand, the issues you are facing is identifying a client in request and correlate different client request i.e. have something like a session.
Spring also support RMI over HTTP protocol (Using Hessian and its own HTTP Invokers). Check out this link (Section 17.3). Now once you have transport as HTTP, it has inherent Basic Authentication and session which can be leveraged to get around the issues you are facing.
This is just a pointer. I would be curious to know how eventually you resolved your problem.