In my Luminus app I have this:
(defn page1 [id]
(layout/render "page1.html"
{:article (db/get-single-article {:id (Integer/parseInt id)}))
I want to perform multiple different requests to the db within the same db connection. How can I do that?
From your question it's not clear whether you want to reuse the same DB connection to handle multiple HTTP requests or single HTTP request calling multiple functions using JDBC API (so all those JDBC calls use the same DB connection).
If this is the latter case you can use with-db-connection to wrap all your functions calling JDBC API. You can also use with-db-transaction if all SQL operations should be part of one DB transactions.
For the former case I am not sure why you would need to reuse the same connection for multiple HTTP requests but it is not a common idiom as HTTP is stateless by definition and causes multiple issues.
You might store the connection in your ring HTTP session so you can fetch it whenever you get a request associated with the session and use for JDBC logic.
However, such a solution has following drawbacks:
you have to make sure that the connection gets released to the pool (or closed if you don't use pooling) when is no longer needed. How would you detect that? What if the client fails and never finishes some workflow where you decide to clean up the DB connection?
how many concurrent 'sessions' do you need to handle? If many (like hundreds) keeping a dedicated connection for each session won't scale (DB connections are expensive resources on both sides: client and servers)
Related
I am building a REST service which internally calls other services and we use org.apache.cxf.jaxrs.client.WebClient to do this.
I want to use HTTP connection pooling to improve the performance but the documentation isn't very clear about how to do this or if this is even possible. Has anyone here done this?
The only other option I can think of it is to re-use clients but I'd rather not get into the whole set of thread-safety and synchronization issues that comes with that approach.
By default, CXF uses a transport based on the in-JDK HttpURLConnection object to perform HTTP requests.
Connection pooling is performed allowing persistent connections to reuse the underlying socket connection for multiple http requests.
Set system properties (default values)
http.keepalive=true
http.maxConnections=5
Increment the value of http.maxConnections to set the maximum number of idle connections that will be simultaneously kept alive, per destination.
In this post are explained some detail how it works
Java HttpURLConnection and pooling
When you need many requests executed simultaneosly CXF can also use the asynchronous apache HttpAsyncClient. Ser details here
http://cxf.apache.org/docs/asynchronous-client-http-transport.html
Is there a way for a function in PSQL to call a webservice that returns a JSON and use this JSON to perform something in the database within a trigger call ?
psql is the command line client application. So no.
If you mean pl/pgsql, the server side function language, then ... still no. It, by design, cannot make network connections, access files, etc.
You could use PL/Python or PL/Perl to do this... but you shouldn't. If the web service is very slow, there are DNS problems, etc your whole database could slow to a nonfunctioning crawl.
Instead use LISTEN and NOTIFY with an external client to process a work queue and store the results in the database. With PostgreSQL 9.5's SKIP LOCKED this can be done concurrently very easily. With 9.4 and older it's easiest to do it serially, or using one worker managing multiple asynchronous requests.
This is much like the "how do I send email from a stored procedure" questions. You can use plperl or plpython, but you shouldn't.
Problem
We have a client-server application, server side is Glassfish 3.1.2. This app has many users, as well as many modules (e.g. View Transactions, View Banks etc). There are some long running processes invoked by client which run on server. Currently we have not found a nice solution to show the user what is going on on the server side. We want the users to get updated messages from server with given frequency. What would you suggest to use?
What we have done/tried
We (independently) used an approach with Singleton bean and a Map of client IDs similar to this, and it works of course. But then on the server side every method doSomething(Object... vars) must be converted to doSomething(Object... vars, String clientID) or whatever ID is type of. The client pulls data from server say once per second. I would like to avoid adding facades between server and client.
I was thinking about JAX-WS or JAX-RS, but I'm not familiar with these technologies deeply and not sure about what they can do.
Sockets
I should note that on the server side we have only Stateless beans (there is a reason for that), that is why I did not mention the use of Stateful bean (which is very good candidate I think).
Regards, Oleg
WebSocket could be a suitable choice, it allows the server to send unsolicited data to clients with no strong coupling, you just have to store a client id to map client connections to running tasks and be able to push updates to the right connection.
The client id/socket connection mapping can be maintained in a singleton bean using an in-memory structure, i.e. a hash map, or a permanent datastore for scalability purposes or in case you need a robust solution.
Some useful links to better understand WebSocket technology are this and this.
I have a system where the user needs to connect to first and then based on the connection fetch some data. For e.g. you connect to a database and then fetch say metadata about a table say.
I was planning to expose this via REST API. So in this case, you need to first connect and then use that connection to fetch the metadata.
Two options come to my mind:
a. Have a url say /connect where you post the connection parameters to and it returns a conneciton id. This id is then encoded in subsequent URL to identify the connection.
b. Second option is to post the connection parameters everytime.
What are the pros/cons of these approaches? Are there any other alternatives?
One constraint is that the authentication mechanism to connect to the system is not in my control, I am just exposing some data from the systems via webservices and I am exploring using REST.
Do you really need to expose the connection?
I think it may just be semantic prejudice - but usually connection details are hidden by the service.
Does the connection have business value?!
If the connection does have business value, then treat it like a resource:
i.e.
do a post on /connections to return a new connection
then do a get on /connection//metadata to get the metadata about that connection.
What kind of server do you people see in real projects?
1) Web Services MUST be stateless: Basically you must send username/password with every request, every request must use HTTPS and I will authenticate and load the User object everytime if needed.
2) A Session for Web Services: like in a web container so I can at least save the authenticated User object and have something similar to a session ID so I don't need to authenticate, load and check the User on every request.
3) Sticky Service (persistent service across requests): https://jax-ws.dev.java.net/nonav/2.1/docs/statefulWebservice.html
I understand the scalability problems of stateful services (and of web application sessions), but sometimes you must have some kind of state, for example for a shopping cart. But you can also put this state in the database (use the back-end as a kind of session argh) or passing the entire state to the client (the client becomes responsible for resending the entire shopping cart).
The truth is, at least for web applications, the session helps a lot in many situations. Scalability issues can be ignored if your system accepts that "the user must start over doing whatever he is doing if his web server happens to go down" or you can try a session cluster if that's unacceptable.
How it is for web services? I am inclined to conclude that web services are very different than web applications and accept option 1) (always stateless), but it would be nice to hear other opinions based on real project experience.
While it's only a small difference but it should still be mentioned:
It's not state in web services that kill scalability, rather it's state on the App Server that's hosting the web services that will kill scalability. The moment you say that this user needs to access this server (as done in sticky sessions) you are effectively limiting your scalability options. The point you want to get to is that 'Any of your free load-balanced App servers' can handle this web service request and if I add 1 more App Server I should be able to handle % more users.
It's totally fine (and personally recommended) if you want to maintain state to pass in an authentication token and on each request get the service to retrieve your 'state' from a data store (preferably a redundant and partitioned one, e.g. distributed+replicated key/value data store). That's how Amazon does it with SimpleDb and Google with BigTable.
Ebay takes a slightly different approach and stores most of the clients state in a cookie so it gets passed in with every request. Although it generates a lot more traffic, it still scalable as any of their servers can still handle the request.
If you want a scalable data store I would recommend looking at redis it has speed and features that can't be beat in a key/value data store.
You should also check out highscalability.com if you want access to good material on how to build fast and scalable services.
Ideally webservices (and web sites) should be stateless.
Unfortunately this takes very well thought out problem domain, and clear separation of concerns.
I've found that in practice most real-world web sites depend on state even though this limits their scalability.
I've also found that many real-world web-services also rely on state.
Ultimately the 'right' decision is the one that works for the specific problem, so it's probably okay to write a webservice that relies on state, and refactor it later if scalability becomes an issue.
Highly dependent on whether the service is single transaction oriented (say getting stock quotes) or if the output from the service is dependent on a data provided from a particular client across multiple transactions(in that case state must be maintained.)
As far as scalability issues, storing state in a database isn't actually a bad way to go (in fact it's probably the only way to go if you're load balancing your service across a server farm.)
I think with Flex clients the state is moved out of the service and into the client tier. Keep the services stateless and let the clients maintain the state needed. The services stay simple, and the clients are free to mash them together as they wish.
You seem to be equating state and authentication. Perhaps you're accustomed to storing username and password in session state?
This is not necessary, even with old ASMX web services. Simply pass whatever information you need to your "Login" operation. This operation will be defined to return an "Authentication Ticket" header.
All other operations that require authentication will require this "Authentication Ticket" header. They will each check the header to see if it represents a valid, authenticated user. If so, then they will perform their task. If not, then they will return a SOAP Fault indicating that authentication is required.
No state is required. Simply make sure that the authentication ticket can be validated on any server your service runs on (for instance, in a web farm), and you'll be fine.