I think somebody is confusing their patterns. I've got one guy telling me to use thread pooling and another telling me to use a ConnectionFactory (granted the second guy is not a software engineer, but a very knowledgeable system architect). I'm going to use thread pooling, so we can keep the number of connections to a reasonable number of threads. I've looked all over the internet and I cannot see anywhere where anyone is using both together. I'm thinking about dumping the ConnectionFactory, because it seems redundant at the very least and I just cannot see why or how to use both.
Just curious to see if somebody more knowledgeable than me has ever seen the two used together and can enlighten me as to why.
Also, each connection has to have its own instance of several other classes and we are using a pub-sub architecture. I need to make sure that the subscribers are NOT getting a published message that belongs to another connection. Can I manage that with a ConnectionFactory or do I absolutely need to use a new thread to ensure separation between connection processes?
Just looking for some direction here.
Thank you.
In general Factory pattern is how to create an object. So ConnectionFactory pattern abstracts the way Conncetion is created.
Thread pool abstracts the way threads are managed, i.e. the main things are: when they are started, how many of threads are runnable, their scheduling, their stopping - not creation process!
You can use both this patterns. Your pool can use factory to properly create thread or connection objects.
Related
I have a connection pool with 50 connections.
I want to dedicate
10 among these to task A
20 for task B
Is this a good practice? Is this possible in java while creating connection pools or thread pools?
Sharing resources between different participants is a good practice.
It is also a well-established practice to not do that blindly, but in context of priorities/goals/policies. Very often that happens on a higher level (think of load balancing); but of course, you could also built that into your application directly.
But to my knowledge, there are no simple mechanism in the (standard) java libraries to do that.
Long story short: if you want to use something like this; then you might have to step back and implement your own solution. In other words: you create your own connection pool that knows about "different" tasks; and that allows you to give priorities to them; and then the pool decides on such policies who will be served next.
On the downside: implementing something like this can turn out pretty complicated pretty quickly. Thus my first advise: go for two independent pools; make experiments and see how things work out for you. Only when you find that this solution is too inefficient for you; then start looking into your building your "load balancing"!
My program is using connection as parameter.
For example, I define connection parameter in my main class then I pass the connection as parameter when I call method from another class. would it make any difference to the program performance if i replace with connection pool?
You absolutely do not worry about performance on such a "naive" level. You only focus on performance when you see performance issues (note: of course, you avoid to do outright stupid things). And when you see real performance problems, you do profiling in order to understand the real problems.
In other words: you should focus on creating a good SOLID OO design instead. And (as far as that is possible without seeing any code of yours) from that point of view, you definitely stick with passing in a Connection.
You see, you have some "client" code that is supposed to do "something" with that connection. So the responsibility of that client is exactly that: to use that connection to manipulate whatever that Connection connects to. It should not be the responsibility to also "establish" that connection.
Meaning: one piece of client code is responsible for fetching a Connection from the Connection Pool; and some other client code is responsible for using that Connection to do whatever. You should not mix those two aspects. Otherwise you reduce your options to re-use the individual functionalities; and you couple elements, that simple do not need to be coupled.
I am wondering why there is so little documentation about Thread Groups on the internet ?
Are they still used or they are some stale concepts ?
Can some one explain:
What they are.
What they are used for.
If they are stilled used, where ?
Give some real application examples (web servers like, maybe).
They are used as a Group of Threads. In a simple application you only need one, but in a more complex application server it makes sense to have one for each application.
why there is so little documentation about Thread Groups on the internet ?
I guess some assume it's a pretty simple idea. Not sure what is missing about it.
Are they still used or they are some stale concept ?
I would image most developers never think about Thread Groups. But I think they are useful in certain situations. We have a library where we have a custom ThreadGroup for resetting thread affinity.
Can some one explain that are they what they are used for, if still used, and give an example.
Mostly in applications servers, each server has it's own collection of threads and can be managed collectively. If you want to monitor or shutdown an application your need to know which threads the application started.
If you start off a thread in a ThreadGroup, every Thread it creates will also be in that thread group. Without this feature, you would have a hard time assigning threads to applications.
From #biziclop: How do you reliably enumerate threads in a group?
You can get the size of activeThreads and enumerate as the ThreadGroup locks on this (for better or worse)
synchronized(threadGroup) {
Thread[] threads = threadGroup.activeCount();
threadGroup.enumerate(threads);
// use threads before the lock is released or it could be wrong.
}
In application based on HornetQ engine I intend to create multiple Producers and Consumers.
I have learned, that I should reuse resources as much as possible thanks to this page.
Does that mean, that for my application I should crate one and exactly one ConnectionFactory, one Connection, one Session and then (using this Session object) creating as many Producers/Consumers as I want?
That shouldn't be hard, but I'm not sure if this is the proper approach.
The best rule of thumb for minimum resource usage is to use the fewest constructs as possible while remaining thread safe. Accordingly:
Connection Factories are thread safe: One per JMS server (or one per JMS server per destination type for topics and queues)
Connections are thread safe: Depending on the application architecture, you may be able to use one connection, but I would not bend over backwards to do this.
Sessions and all constructs below the session are NOT thread safe: You will need one session per concurrent thread (or per transaction if you think about it that way).
Based on that, hopefully you can strike a balance between an elegant architecture and low resource utilization.
I have a Java program consisting of about 15 methods. And, these methods get invoked very frequently during the exeuction of the program. At the moment, I am creating a new connection in every method and invoking statements on them (Database is setup on another machine on the network).
What I would like to know is: Should I create only one connection in the main method and pass it as an argument to all the methods that require a connection object since it would significantly reduce the number of connections object in the program, instead of creating and closing connections very frequently in every method.
I suspect I am not using the resources very efficiently with the current design, and there is a lot of scope for improvement, considering that this program might grow a lot in the future.
Yes, you should consider re-using connections rather than creating a new one each time. The usual procedure is:
make some guess as to how many simultaneous connections your database can sensibly handle (e.g. start with 2 or 3 per CPU on the database machine until you find out that this is too few or too many-- it'll tend to depend on how disk-bound your queries are)
create a pool of this many connections: essentially a class that you can ask for "the next free connection" at the beginning of each method and then "pass back" to the pool at the end of each method
your getFreeConnection() method needs to return a free connection if one is available, else either (1) create a new one, up to the maximum number of connections you've decided to permit, or (2) if the maximum are already created, wait for one to become free
I'd recommend the Semaphore class to manage the connections; I actually have a short article on my web site on managing a resource pool with a Semaphore with an example I think you could adapt to your purpose
A couple of practical considerations:
For optimum performance, you need to be careful not to "hog" a connection while you're not actually using it to run a query. If you take a connection from the pool once and then pass it to various methods, you need to make sure you're not accidentally doing this.
Don't forget to return your connections to the pool! (try/finally is your friend here...)
On many systems, you can't keep connections open 'forever': the O/S will close them after some maximum time. So in your 'return a connection to the pool' method, you'll need to think about 'retiring' connections that have been around for a long time (build in some mechanism for remembering, e.g. by having a wrapper object around an actual JDBC Connection object that you can use to store metrics such as this)
You may want to consider using prepared statements.
Over time, you'll probably need to tweak the connection pool size
You can either pass in the connection or better yet use something like Jakarta Database Connection Pooling.
http://commons.apache.org/dbcp/
You should use a connection pool for that.
That way you could ask for the connection and release it when you are finish with it and return it to the pool
If another thread wants a new connection and that one is in use, a new one could be created. If no other thread is using a connection the same could be re-used.
This way you can leave your app somehow the way it is ( and not passing the connection all around ) and still use the resources properly.
Unfortunately first class ConnectionPools are not very easy to use in standalone applications ( they are the default in application servers ) Probably a microcontainer ( such as Sping ) or a good framework ( such as Hibernate ) could let you use one.
They are no too hard to code one from the scratch though.
:)
This google search will help you to find more about how to use one.
Skim through
Many JDBC drivers do connection pooling for you, so there is little advantage doing additional pooling in this case. I suggest you check the documentation for you JDBC driver.
Another approach to connection pools is to
Have one connection for all database access with synchronised access. This doesn't allow concurrency but is very simple.
Store the connections in a ThreadLocal variable (override initialValue()) This works well if there is a small fixed number of threads.
Otherwise, I would suggest using a connection pool.
If your application is single-threaded, or does all its database operations from a single thread, it's ok to use a single connection. Assuming you don't need multiple connections for any other reason, this would be by far the simplest implementation.
Depending on your driver, it may also be feasible to share a connection between threads - this would be ok too, if you trust your driver not to lie about its thread-safety. See your driver documentation for more info.
Typically the objects below "Connection" cannot safely be used from multiple threads, so it's generally not advisable to share ResultSet, Statement objects etc between threads - by far the best policy is to use them in the same thread which created them; this is normally easy because those objects are not generally kept for too long.