My web service server side application serves the stored procedures for the request from different users. I am opening and closing the ADO Connection for each request. Is it advisable or can any one suggest a better method? And help me in session management.
Thanks in advance.
ADO supports connection pooling, so enable it on your Connectionstring property of TADOConnection
Creating a new connection from blank can be very time consuming (e.g. more than 1 second with a remote Oracle connection), therefore is to be avoided like hell for a service application.
IMHO the best solution (from the performance POV) is to maintain one DB connection per server thread. So it will depend on your HTTP service implementation.
Connection pooling is also available if you don't want to deal with threads, as Mohammed wrote in his answer.
Consider also using server-side caching of answers. If you know that the result will be consistent, you should better cache it on the server side and share it among clients. Of course, this is worth developing only if client requests may share.
About session management, what do you want to know? I guess this is about Client sessions. For a web service, the main usage is to implement a session via cookies. See this SO answer about authentication of a web service, for other possibilities. IMHO a RESTful approach (i.e. stateless) is worth considering for a web service.
Related
This article describes how a websocket server for a chat application can look. We are planning to implement something similar; when a message is sent to the server it is sent to the correct recipient based on an authentication token and the message gets saved in a mysql database.
We will eventually host the server on Google App Engine, and I suspect that that will cause some issues with the above described approach, since that depends on all clients being connected to the same server, and that probably won't be the case since multiple instances will be created as needed. Is there a way to connect all instances so that this won't be a problem (Pub/Sub maybe? (That will cause additional costs though)), or should we find a different solution?
One idea I had was to use mysql-events to monitor the binlog from the websocket server for the creation of new rows in the messages table, but I read somewhere that that wasn't recommend. But I can't find where I read that, and maybe that is the best solution.
Since you asked about other solutions, I would recommend looking at Firebase and specifically the Realtime Database. Out of the box it provides all of the functionality that you need for realtime communication between connected clients and Cloud Messaging for clients who aren't.
Here's a tutorial that uses Firestore to create a realtime chat web app, but it can all be applied to the Realtime Database with minor modification. I say that because Firestore has expensive writes, which in my opinion make it unsuitable for a chat backend.
I am trying to Ajax load from LAN's mysql using chrome app.
I am proposing Ajax because I need chrome app to load up any update in the SQL instantaneously.
Since this app is only used in LAN network, I presume there is no need to maintain a web server (aka running Apache). Can anyone provide some hints as this answer I found on the forum does not help me (an absolute newbie) too much.
https://developer.chrome.com/extensions/xhr
Thank you.
YY
Since this app is only used in LAN network, I presume there is no need to maintain a web server (aka running Apache).
AJAX refers to making a HTTP request to.. something.
Something that can answer HTTP requests is called a web server.
So, you do need some sort of web server. It may be a component of MySQL server, but it's still a web server.
That said, it doesn't look like MySQL has a supported HTTP interface. There is an experimental HTTP Plugin that provides REST API, but it's experimental. Therefore, you would need a separate server application that does what you need.
That said,
I am proposing Ajax because I need chrome app to load up any update in the SQL instantaneously.
AJAX is not a magic bullet. It works well for requesting data, but it is not adapted to receiving updates initiated by the server you're talking to. It's a request-response cycle, and while there are some techniques to use it to push data they are hacks.
WebSockets evolved to cover the bidirectional, persistent communication needs. However, this again would require a web server to sit as a proxy between your DB and your app - this time, WebSockets-capable.
That said, building a Chrome App allows you to connect to a database directly - since Chrome Apps are capable of using chrome.sockets API. You would need a JavaScript library specifically adapted to the task, but those probably exist.
That said, and noting that I'm not an expert on databases, but..
Databases are not designed to notify you about updates. You need to poll them to see if the data has changed. You will not get it instantaneously no matter what interface you use. You'll need to periodically monitor it for changes.
Considering this, depending on what you're trying to ultimately do you may be choosing a wrong instrument.
There's a lot of "buts" here, and it seems like a complex task. You should re-evaluate your readiness as an "absolute newbie" to undertake it.
I have a realtime HTML5 canvas game that runs off a node backend. Players are connected via Websocket (socket.io). The problem is sometimes I need to deploy new code (hotfixes for instance) and restart the server but I don't want to disconnect players.
My idea for this was to divide the websocket server and application server into separately deployable components and add a message queue in the middle to decouple the 2 components. That way if the application server was rebooting there would just be a short delay while the messages bunch up but nothing would be lost. Is this a good strategy? Is there an alternative?
It's very possible for websocket based applications to be restarted without the user noticing anything (that's the case for my chat server for example).
To make that possible, the solution isn't to have a websocket application isolated and never restarted. In fact this would be very optimistic (are you sure you could ensure its API is never changed ?).
A solution is
to ensure the client reconnects if disconnected (this is standard if you use socket.io for websocketing)
to make the server ask the client its id (or session id) on client initiated reconnection
to persists the state of the application. This is usually done with a database. If your server has no other state than the queue between clients (which is a little unlikely) then you might look for an existing persistent queue implementation or build your own over a fast local storage (redis comes to mind)
I'm new websocket streaming application.
I'm trying to evaluate kaazing and solace streaming vendor products.
I'm trying to put a layer or interface application infornt of kaazing publisher before it creates the socket connection.
The client would make request to the interface for the socket connection , the interface plays the role to authenticate and authorize and do some business changes before the creation of socket.
The interface establish the secured socket connection with kazzing or streaming application and transfer the connection object to the client in response.
The client use the established connection from the reponse and retains the connection for streaming the data to client from the streaming server.
The objective is to hide the topic info and connection established from the client side for secured process.
So the infterace creates the secured connection and transfers the connection to authorized client which continue the streaming from the streaming server until the session expires.
Please let me designing such an application is possible.
The client receives data but it doesn't establish connection of its own, its created from server side and transfered to client side after all necessary validation.
Guide me to proceed further with the design and I'm inneed of expert's valuable suggestion.
Thanks in advance and appriciated for directing me to the right path in designing the streaming appliation.
My aim is not to introduce a new layer between the gateway and client. Altimate aim is to customize the gateway for my product, For example the user(client) connects to gateway and tries to access the topic say stock(eligible to subscribe) then he will be able to get the data streaming. If he needs share he would register is some place and after approval only he will be eligible to view, So authorization would play a role and maintaince a session and loads the customized data and allows to stream.
Typically am trying to have a dashboard of data streaming. So only authorized streaming is allowed for user. Also he will be able to see all the topic name. whether its possible to use proxy name , example 1, or 2 might be the value he would use from client side, when it reaches the gateway it verify the authorization and replace the value with real topic name and establish the data.
Please let me know whether I've my question clear. Your valuable suggestions and guidance will be more helpful to continue with my research.
Thanks
Krish
in case you wonder how the world has changed over the last five year to address this kind of need, now you could give a try to streamdata.io, a proxy which uses SSE protocol (unidirectional) and is available in minutes. It would perfectly fit what's needed in the example given, because Im not sure WebSocket is the ideal answer here. Tho it should work, it's basically like buying a harvester to go get your kids at school.
As a disclaimer, I need to say that I work for Streamdata, and we see this kind of thing every day.
WebSocket is great if you need bidirectional streams of data, like in chats or games. Most of the time, when the clients mainly expect updated data from the server, instead of polling AF or deploying WebSocket, SSE is the best alternative as it's easier to deploy (http, etc.). The rest of the settings (for security) can be done through the proxy interface.
Boom: it's available before you even realize it, it's secure, easy to maintain and more efficient than before. You have more time available to answer questions from the community over here; your team is happy; your boss loves you more than before and might even give you a raise. Life can be so simple sometimes!
I am writing my first .NET MVC application and I am using the Code-First approach. I have recently learned how to configure two SQL Servers installations for High Availability using a Mirror Database and a Witness (not to be confused with Failover Clusters) to do the failover process. I think this would be a great time to practice both things by mounting my web app into a highly-available DB.
Now, for what I learned (correct me if I'm wrong) in the mirror configuration you have the witness failover to the secondary DB if the first one goes down... but your application will also need to change the connection string to reference the secondary server.
What is the best approach to have both addresses in the Web.config (or somewhere else) and choosing the right connection string?
I have zero experience with connecting to Mirrored databases, so this is all heresy! :)
The short of it may be you may not have to do anything special, as long as you pass along the FailoverPartner attribute in your connection string. The long of it is you may need additional error handling to attempt a new connection so the data provide will actually use the FailoverPartner name in the new connection.
There seems to be some good information with Connecting Clients to a Database Mirroring Session to get started. Have you had a chance to check that out?
If not, its there with Making the Initial Connection where they introduce the FailoverPartner attribute of the ConnectionString property attributes.
Reconnecting to a Database Mirroring Session suggests that on any client disconnect due to failover, the client will need to trap this exception and be prepared to reconnect:
The application must become aware of
the error. Then, the application needs
to close the failed connection and
open a new connection using the same
connection string attributes.
If the FailoverPartner attribute is available, this process should be relatively transparent to the client.
If the above doesn't work, then you might need to actually introduce some logic at the application tier to track who is the primary node, the failover node, and connection strings for each, and be prepared to persist that information somewhere - much like the data access provider should be doing for us (eyes wide open).
There is also this ServerFault post on database mirroring with Sql Server that might be of interest from an operational viewpoint that has additional reference information.
Hopefully someone with actual experience will back up any of this!
This may be totally off base, but what if you had a load balancer between your web server and the database servers?
The Load Balancer would have both databases in it's pool, using basic health check techniques (e.g ping, etc).
Your configuration would then only need to point to the IP of the Load Balancer, and wouldn't need to change.
This is what these network devices are good for. It's not the job of the programming framework (ASP.NET) to make decisions on the health of servers.