I have been doing a lot of research online but can't seem to find a definitive answer to my question which is why I turned to the experts on this site.
When developing with java and Tomcat I have a Singleton class that handles my database connection. So the question is when different users connect to my web application, and my server side java code executes does it get its own singleton class?
For example:
User A logs into my site. An instance of my singleton is created.
User B logs into my site, does the same object (singleton) persist between the two executions of the java code? or is each execution for user A and user B get different singletons?
thank you.
A singleton, stored in a static field, is unique per classloader. So all users of your web application on a tomcat instance would be using the same singleton.
A singleton means a single instance per JVM (per classloader, to be precise). Tomcat does not have seperate environment per user. Instead, it has seperate classloader (and hence separate environment) per web application. Hence, no matter how many users are connected the server side is a single environment and this environment has a single instance of your singleton class which is shared by all the classes loaded in that environment.
Related
Please consider me as a novice and this is my first web app I am creating.
I am planning to develop a web application where the traffic I am expecting is around 50 users will access the application at a single time.
The webapp is developed with Vaadin (for UI) and respective business logic implemented with Java. DB used would be MySQL. The war will be deployed in Tomcat.
So, my question is do I need to modify anything in Tomcat properties or anywhere to make the web app as multi user application (i.e. each users need to access and use application as though they are only one using the application)?
I tried to access a prototype developed using Vaadin in both Chrome and Firefox and could see both sessions running without an impact on another.
But please let me know suggestions.
You must keep in mind that even if tomcat and vaadin manage multiple sessions, your server application will have only 1 instance. So if you use singletons, static methods or fields, use them with care: they should never hold session-dependant content. Try to favour stateless methods over statefull.
Apart from that, there shouldn't be any problem.
It should not have any code changes if you handle the session and your business logic with statefulness properly.
There might be some configuration changes, like increasing the database connection pool size, it depends on what kind of connection pooling you are using and what is the default size etc.
Apart from that it should work just fine.
Vaadin is built on top of Jakarta Servlet technology (formerly known as Java Servlet). See Wikipedia. Indeed, Vaadin is a servlet, a much bigger and more sophisticated servlet than most.
Within a Java Servlet container (engine) such as Apache Tomcat or Eclipse Jetty, any particular servlet has only a single instance running. If three requests from three users arrive at the same time, there are three threads running through that same single instance for that particular servlet. So a servlets are inherently a highly threaded environment.
If you share any variables or resources between those threads, you must be very careful. That means mandatory reading, rereading, and fierce study of the book Java Concurrency in Practice by Brian Goetz, et al.
While the Web and HTTP were designed to be stateless delivery of single documents, that original vision has been warped by the desire to make web apps. To maintain state, a servlet automatically maintains a session. Vaadin represents this session state in its VaadinSession object. All data in all the forms, along with business logic, running for each user is maintained as part of that session.
Depending on your particular Vaadin app, and when multiplied by the number of concurrent users, this may add to a large amount of memory. You should monitor your server to make sure you have enough available RAM on your server.
do I need to modify anything in Tomcat properties or anywhere to make the web app as multi user application (i.e. each users need to access and use application as though they are only one using the application)?
No, nothing for you to set or enable. Tracking the requests/responses and session for each user is the very purpose of a servlet container. From the moment it launches, every servlet container expects multiple users. As a Servlet, Vaadin is built to expect multiple users as well. The only trick is making your own code thread-safe, hence the book suggestion.
I tried to access a prototype developed using Vaadin in both Chrome and Firefox and could see both sessions running without an impact on another.
Concurrency problems can be very tricky to detect and debug. Often potential problems occur on the random chance of coincidental timing. You need to focus on properly designing your code in the first place, rather than relying on testing. Again, hence the book recommendation.
Of special note, since you mentioned using a database, is JDBC drivers. Deploying them in a Servlet environment can be tricky. Basically you need to not bundle them within your Vaadin web app WAR file. Instead, deploy the JDBC driver separately within a shared library folder within Tomcat. If using Maven to drive your project, direct Maven in the POM file to give the dependency for your JDBC driver a scope of provided. This has nothing to do with Vaadin specifically, it applies to all servlets. Search Stack Overflow as this issue has been extensively addressed.
Does every web application in web container will run in an isolated memory space? Is it a stand alone PROCESS?
Does every servlet run in an isolated memory space or a process?
What's the diff between java process and os process, Does every java process will run in an OS process?
Application data are isolated from the other applications in same web container like Tomcat or application server like jboss or Webloogic. But you should be aware that java Servlets are Classes that serve web based requests and nothing more!
as you know Classes are templates for creation objects or in technical speech for instantiation of objects, so usually web containers at the start up state or application deployement state create some objects from Servlet classes ready to use for serving requests (Servlet pool)
the next thing that would be fine to mention here is that if you declare a variable in Class scope you are using this variable in none thread-safe manner, it means that it is shared by other instances.
if you do some practice on this kind of variables(class scoped variables) you can see results and odd value changes!
After reading this very same topic about Java Servlets:
How do servlets work? Instantiation, sessions, shared variables and multithreading
I started looking for documentation about how this works for LCDS or Blaze remote objects on flex without any luck so far...
so, does any one knows about good documentation or its experienced enough to answer this?
I'm currently using flash builder 4.6, ADEP Data Services for Java EE 4.6 and JBoss 7.1.
Edit: I'm gonna specify some of my doubts on remote objects:
If the scope is application, is the class instanced on application start up like java servlets?, whats the concurrency behavior on different scopes?, are request scope objects created and destroyed on each call?, what about static members?.
My experience is limited, and with GraniteDS (which from my understanding is very similar to BlazeDS in how it works ). AMF calls hit a servlet (which I think is called MessageBrokerServlet). This servlet will call the configured service. The AMF servlet works like any other servlet, and follows the same life cycle. Your service classes do not follow this life cycle, and are by default managed by BlazeDS. You can read more about the scope of the destination (the services exposed by BlazeDS) here. You can configure one of three scope(request scope, the application scope, or the session scope )Hope this helps.
Is is possible to create a universal Singleton class, which is, at any given time, only one instance is shared across multiple Java processes?
Multiple Java processes don't share the same virtual machine.
So you would end up with one JVM instance hosting the singleton, then one JVM instance per process which access the singleton using Remote Method Invocation as #Little Bobby Tables suggested.
Anyway consider When is a Singleton not a Singleton:
Multiple Singletons in Two or More Virtual Machines
When copies of the Singleton class run in multiple VMs, an instance is created for each machine. That each VM can hold its own Singleton might seem obvious but, in distributed systems such as those using EJBs, Jini, and RMI, it's not so simple. Since intermediate layers can hide the distributed technologies, to tell where an object is really instantiated may be difficult.
For example, only the EJB container decides how and when to create EJB objects or to recycle existing ones. The EJB may exist in a different VM from the code that calls it. Moreover, a single EJB can be instantiated simultaneously in several VMs. For a stateless session bean, multiple calls to what appears, to your code, to be one instance could actually be calls to different instances on different VMs. Even an entity EJB can be saved through a persistence mechanism between calls, so that you have no idea what instance answers your method calls. (The primary key that is part of the entity bean spec is needed precisely because referential identity is of no use in identifying the bean.)
The EJB containers' ability to spread the identity of a single EJB instance across multiple VMs causes confusion if you try to write a Singleton in the context of an EJB. The instance fields of the Singleton will not be globally unique. Because several VMs are involved for what appears to be the same object, several Singleton objects might be brought into existence.
Systems based on distributed technologies such as EJB, RMI, and Jini should avoid Singletons that hold state. Singletons that do not hold state but simply control access to resources are also not appropriate for EJBs, since resource management is the role of the EJB container. However, in other distributed systems, Singleton objects that control resources may be used on the understanding that they are not unique in the distributed system, just in the particular VM.
Yes, but not without external facilities. The simplest way is to use RMI. Other options include CORBA or Web Services - Just google it up.
Revising some past exam papers for an exam mainly focus on component-oriented design and J2EE, I have come across the following question:
A preliminary investigation of scenario 3: “Exchange Request” suggests that two EJBs will provide a suitable solution: a session bean called EnterExchangeRequest to control the processing and an entity bean called ExchangeRequest to represent the persistent properties of the request. Discuss the role of the following interfaces:
Home
Remote
LocalHome
Local
and how they would provide access to the services of the EJBs described above.
I could try to explain how Home and Remote interfaces would fit into the picture. I have also heard the lecturer say one could replace Home by LocalHome, and Remote by Local (why?), but why are they asking me to discuss the role of all four at the same time?
Do I get it right when I say, the EJB container (the application server) would see that an interface is Home or Remote and then decide that the bean can 'live' on any machine in the cluster, while in the case the interfaces are LocalHome and Local the container will know that the beans can't be distributed across multiple machines and will therefore keep them 'alive' in one machine only?
I am totally lost in this enterprise Java jungle. I am experiencing a BeanOverflow. Could you please tell me which of my assumptions are wrong, point out my misconceptions and blunders.
Thank you all who are willing to help me with these EJB interfaces.
P.S. Note that I am not asking you to answer the question from the past exam paper. Just curious if you have any thoughts as to what could they be after when asking this.
As pointed out by Yishay, Home/Remote and LocalHome/Local are tied together and the Home interface functions as a constructor.
Local beans are tied to the JVM they live in, you can not access them from the outside. Remote beans can be accessed from other JVMs.
I use a similar approach: I always deploy ears. Beans for the ear I make local beans, Beans meant for use by other ears I make remote. But it is possible to use the local beans in other ears, as long as the are deployed in the same JVM
Home is responsible for the creation of the Remote (kind of like its constructor) and LocalHome and Local have the same relationship.
In each case the container is giving you a proxy that references the real EJB class that you write.
If I had to guess, what the question was looking for was the use of remote for the session bean and local for the entity bean.
Anyway, although these concepts can still exists, things have been much better simplified in EJB3.
EDIT: In response to the comment, with EJB3, the bean class itself can implement the remote and the home interfaces directly (for the session beans). They are made EJB's with a single annotation. Stateful beans have a couple more annotations to deal with state issues. Entity beans do not have a Home interface, and do not need a local interface, you can interact with the java object directly. There is an EntityManager that retrieves the right entity beans based on a query, and that EntityManager is injected via an annotation.
That kind of sums it up in a paragraph. There are great tutorials on the web for this stuff, but EJBs in general solve a class of problem that is hard to appreciate unless you deal with the problem. They aren't the only way to solve it, but unless you deal with this type of programming, just reading about it won't really help you relate to it.