I am developing Spring Web application where many user interact with database cocurrently.i am using SpringJdbcTemplete for communication with database. I have following two beans define.
I only need one Datasource so its defult scope should be Singleton. I have
jdbcTemplate bean autowired to different service class(Admin and user service class).Since my application user can concurrently access this jdbcTempelete instance what should be its defult scope..?
I found that it should be Singleton. But If it is Singleton that only one instance of it will be created and is shared among many requesting user.In this secenerio suppose 1000 user try to access jdbcTemplate at the same time that 999 user have to wait to get it. am iwrong in that if yes please help to avoid my confusion. thanks
As explained in the javadoc of JdbcTemplate the class is thread safe after construction. So as soon as an instance of JdbcTemplate is available it can be shared amongst different threads.
The JdbcTemplate is thread safe and can be used concurrently between multiple threads.
When a bean is thread safe there is nothing preventing you to use a single instance between any number of threads.
More information on using Spring and JDBC Access can be found in the reference guide
Related
I want to make database queries in my Jersey REST webapp. The ideal situation would be to find a way where the database connection is initialised once at the first app run. Afterwards I only get the instance of DAOFactory object in my REST class and make the queries in the methods. I am using mysql connector. Is there a way to find a way to do it in Jersey? In JSF it was possible - I just used an application-scoped bean when I run the code. Moreover it would be good if I could access the ServletContext object inside this method cause I would like to use it's getResourceAsStream() method to read the database connection parameters from WEB-INF/dao.properties file. But the 'only once per app initialisation' is the crucial part here.
I have a simple application that fetches some data from ONE table on db (MySQL 5.1) via Hibernate and display the content. The main framework used is Spring 3.0. The query runs correctly in #Transactional(read-only) (+second cache level).
The problems come out running some concurrent tests with 20/30 requests against the same page. Some page-requests return 500 instead of 200. I suppose that is due to #Transactional doesn't manage multi-thread access (pls correct me if I am wrong).
In the controller I have something like this:
List<String> names = usersService.getUserNames(); // this executes query in #Transactional env
doSomething(names);
the logs say that "doSomething" threws some NullPointerException as there are not data in the list passed.
Is there a way to implement a multi-thread access manager with Spring+Hibernate that manages concurrent requests to db?
#Transactional is working perfectly fine in multithreaded applications. In fact, all web applications are multithreaded, and each spring bean singleton instance handles all requests. So the issue is not there.
When you get error 500, you should check the logs files. If nothing's there, make sure you haven't swallowed some exception.
You need to make sure that a separate database connection is allocated to every incoming request. Connections should be managed in a pool. The size of the database connection pool would determine (indirectly) how many requests your application can server simultaneously.
We need to get certain information from PortletRequest in our Portal application. We do that using a utility method inside our Portlet Application. In this Utility method we access FacesContext.getCurrentInstance().getRequest() to get the PortletRequest. We access this Utility method in our DAO layer. We do not have access to request parameter here.
It works sometimes, but at times it gives me NullPointerException. I found a similar thread which explains about this. They have mentioned, if it is part of the same request, then you should get the Context. For me, it is part of the same request, but I'm not getting the context. Can you please help me.
If you are getting a null FaceContext from FacesContext.getCurrentInstance() then no FacesContext has been constructed for this Thread/Request.
Are the failing requests coming through a non-faces entry point? Such as an Event or Resource portlet request? If so there will be no FacesContext created.
Rather than relying on static methods and thread local storage to access data in you DAO you should consider extracting what you need from the PortletRequest, and passing it down your stack. It is bad practice to mix presentation layer artefacts such as the FaceContext or a PortletRequest with your DAO layer.
If your application is deployed in separate WAR/JAR files, it is likely that different classloaders are used. I had a similar problem, when I tried to access the FacesContext inside an hibernate HAR archive on JBOSS5. I came up with a successfull solution using reflection API. Take a look at this.
If you bundle your whole application into one EAR, you might be able to force the use of one classloader for the whole ear, but AFAIK that is application server specific.
Regards
I have several clients that create new objects. When new object is created I need to start a timer that will change some object properties when time is elapsed (each object can be visible only for defined client groups certain time).
I want to use for this purpuses web-service and wrote a method that starts timer.
For example I need to set timer to 5 minutes. Are there any restrictions for executing time? Will a timer keep my web-service alive?
Perhaps, I don't understand your task completely, but your idea about Web Service usage looks strange to me. Web Services are usually used to process requests from remote clients. I.e. a client calls method of a Web Service and Web Service returns a result to this client.
I think, I got your idea :). If you need to just change data in the DB, I think the better solution is to create a windows service which will ping web service when needed.
I am planning to use WCF (not ria) in conjunction with Entity Framework 4 and STE (Self tracking entitites). If I understand this correctly my WCF should return an entity or collection of entities (using LIST for example and not IQueryable) to the client (in my case Silverlight).
The client then can change the entity or update it. At this point I believe it is self tracking? This is where I sort of get a bit confused as there are a lot of reported problems with STEs not tracking.
Anyway, then to update I just need to send back the entity to my WCF service on another method to do the update. I should be creating a new OBJECTCONTEXT every time? In every method?
If I am creating a new objectcontext every time in every method on my WCF then don't I need to re-attach the STE to the objectcontext?
So basically this alone wouldn't work??
using(var ctx = new MyContext())
{
ctx.Orders.ApplyChanges(order);
ctx.SaveChanges();
}
Or should I be creating the object context once in the constructor of the WCF service so that 1 call and every additional call using the same WCF instance uses the same objectcontext?
I could create and destroy the WCF service in each method call from the client - hence creating in effect a new objectcontext each time.
I understand that it isn't a good idea to keep the objectcontext alive for very long.
You are asking several questions so I will try to answer them separately:
Returning IQueryable:
You can't return IQueryalbe. IQueryable describes query which should be executed. When you try to return IQueryable from service it is being executed during serialization of service response. It usually causes exception because ObjectContext is already closed.
Tracking on client:
Yes STEs can track changes on a client if client uses STEs! Assembly with STEs should be shared between service and client.
Sharing ObjectContext:
Never share ObjectContext in server environment which updates data. Always create new ObjectContext instance for every call. I described reasons here.
Attaching STE
You don't need to attach STE. ApplyChanges will do everything for you. Also if you want to returen order back from your service operation you should call AcceptChanges on it.
Creating object context in service constructor:
Be aware that WCF has its own rules how to work with service instances. These rules are based on InstanceContextMode and used binding (and you can implement your own rules by implement IInstanceProvider). For example if you use BasicHttpBinding, default instancing will be PerCall which means that WCF will create new service instance for each request. But if you use NetTcpBinding instead, default instancing will be PerSession and WCF will reuse single service instance for all request comming from single client (single client proxy instance).
Reusing service proxy on a client:
This also depends on used binding and service instancing. When session oriented binding is used client proxy is related to single service instance. Calling methods on that proxy will always execute operations on the same service instance so service instance can be stateful (can contains data shared among calls). This is not generally good idea but it is possible. When using session oriented connection you have to deal with several problems which can arise (it is more complex). BasicHttpBinding does not allow sessions so even with single client proxy, each call is processed by new service instance.
You can attach an entity to a new object context, see http://msdn.microsoft.com/en-us/library/bb896271.aspx.
But, it will then have the state unchanged.
The way I would do it is:
to requery the database for the information
compare it with the object being sent in
Update the entity from the database with the changes
Then do a normal save changes
Edit
The above was for POCO, as pointed out in the comment
For STE, you create a new context each time but use "ApplyChanges", see: http://msdn.microsoft.com/en-us/library/ee789839.aspx