M362 2008 Exam (part 2) Flashcards
Give a definition of a thread-safe class.
A class is considered thread-safe if its instances behave under concurrent method calls as if they were called sequentially. In other words, it is not possible for a multithreaded application to observe an instance of that class in an inconsistent state, i.e. a state that could not be observed by a single-threaded application.
Show, using the example scenario, how class Account violates the definition of a thread-safe class.
For the example scenario, a sequential execution of
myAcc.credit(20);
myAcc.debit(15);
will lead to a balance of 15, but with two concurrent threads it could lead to a balance of 30. Consider that T2 is interrupted after computing the sum balance + 20. At that point T1 executes the call to debit,
leaving a balance of −5. Now T2 resumes execution and assigns 30 to balance.
What is the general problem of which the scenario is an example?
This is an example of the lost update problem.
Write a class BlockingAccount which is a thread safe version of Account, and in which, additionally, the debit operation blocks until balance is greater than or equal to the amount to be debited. Note: You must use Java’s built-in mechanisms, NOT the Java 1.5 concurrency utilities.
public class BlockingAccount
{
protected int balance;
public BlockingAccount (int balance)
{
this.balance = balance;
}
public synchronized void debit (int a)
{
while (balance < a)
{
wait();
}
balance = balance - a;
}
public synchronized void credit (int a)
{
balance = balance + a;
notifyAll();
}
}
Explain two limitations of the built-in mechanisms used in the previous question and how they were addressed by the concurrency utilities introduced by Java 1.5.
Java’s built-in monitors are limited in the sense that they have a single implicit condition variable per lock and there is no possibility of retracting lock acquisition attempts.
The concurrency utilities introduced the Lock and Condition interfaces.
The former has a tryLock method that doesn’t block if the lock is not available, and the latter allows the developer to associate multiple explicit conditions to each lock. Note: The exact names of interfaces and methods do not have to be fully correct as long as the explanation is clear.
Explain and compare the thread safety levels of classes Account and BlockingAccount. Discuss why there is a need to identify various thread safety levels and what their existence implies for developers.
Account is thread-compatible because it does not use internal synchronisation and hence requires every method call to be externally synchronised.
BlockingAccount is thread-safe because no external synchronisation is necessary for calling its methods.
Identification of the various thread safety levels is necessary because there are different ways for making classes behave correctly in a concurrent setting (e.g. by making the data immutable or by various degrees of internal and external synchronisation). This means that class developers have to document precisely the class’s safety level and which (sequences of) methods, if any, require external synchronisation.
Describe a schedule for the example scenario, but using BlockingAccount instead of Account, indicating for each thread the states it goes through in the Java Thread state model. Note: Assume the two threads are NOT in the NEW state. For full marks provide a schedule that uses three different states.
We assume both threads are in the RUNNABLE state.
One of them is scheduled for execution, let’s assume it is T1. It acquires the lock on the account, and starts evaluating the while condition. At this moment, T2 is scheduled for execution, it tries to obtain the lock, but since it is held by T1, T2 becomes BLOCKED.
Now T1 resumes execution, enters the while loop (because it is attempting to debit 15 from an account holding only 10) and calls wait.
This releases the lock and T1 gets into the WAITING state.
T2 is now able to get the lock, becomes RUNNABLE and executes the credit operation, which notifies T1.
T1 thus returns to the RUNNABLE state and completes the debit operation.
Using a diagram or otherwise, name the standard tiers of a Java EE application and indicate the type of components associated with each tier.
Client Tier: Browser, applet, application client
Web Tier: Servlet, JSP, JavaBean
Business Tier: EJB, Entity class
Database / EIS Tier: DBMS
Explain the role in Java EE applications of
- stateful EJB session beans
Discuss how each of these might be used in implementing the web application outlined in the scenario above.
Stateful EJBs
EJB session beans are objects that contain the application logic, providing business services to clients.
In a stateful bean, the state (i.e. the value of the bean’s instance variables) is kept across multiple calls to the bean’s methods. A classic example is a shopping cart in an online shop. The shopping cart has to keep its state (i.e. the products it contains) across multiple interactions with the client, who might add and remove products from the cart.
In the scenario, stateful EJB session beans could be used to keep track of the user’s preferences for location, activities, accommodation and so on during the session
Explain the role in Java EE applications of
- stateless EJB session beans
Discuss how each of these might be used in implementing the web application outlined in the scenario above.
Stateless EJBs
In a stateless bean, the state is discarded after each method call, i.e. a session with a stateless bean only lasts for the duration of a single method call.
This makes stateless beans ideal to provide one-off services that are performed always in the same way, independently of the actual client invoking it. For example, a database query can be seen as a complete session by itself, and it isn’t necessary to keep a record of which client executed which query. Therefore a single stateless bean can provide multiple methods, each one implementing an independent query.
In the scenario, stateless EJB session beans could be used for example in retrieving the list of accommodation for a particular location
Explain the role in Java EE applications of
- transactions
Discuss how each of these might be used in implementing the web application outlined in the scenario above.
Transactions
A transaction is a sequence of operations which we want to be performed atomically, that is to be performed in its entirety, or not performed at all.
The classic example of a transaction is a transfer of funds from one account to another in a bank application. This requires a sequence of operations including debiting one account and crediting the other. It is important that either all the operations take place, or that none of the operations takes place.
In the scenario, transactions will be necessary when booking accommodation to ensure that any booking operations (including payment) complete fully or are not carried out at all.
Explain how HTTP servlets deal with the following issues:
- Handling concurrent requests from multiple clients;
Handling concurrent requests from multiple clients
For the standard situation of a multi-threaded servlet, the Web container will create and run a separate thread for the service method that is invoked in response to each request.
The helper methods such as doGet or doPost which will be invoked by the service method must be written to take account of this.
Explain how HTTP servlets deal with the following issues:
- Avoiding problems with concurrent access to shared data.
Avoiding problems with concurrent access to shared data.
Any data stored in variables declared locally to servlet methods is threadsafe, because each thread has its own copy of local variable data.
By contrast, instance variables** or **static variables** are **not thread-safe as they are shared between any threads being run concurrently by the servlet.
Code that updates instance data or static data, must use synchronization, so that at most one thread at a time can be carrying out an update.
Explain whether and how the issues from part (c below) might arise in the tourist information web application outlined in the scenario above.
- Handling concurrent requests from multiple clients;
- Avoiding problems with concurrent access to shared data.
There may be many users simultaneously using the tourist information site, each searching for different regions, activities and so on – each user request will require a separate service thread for the servlet (or JSP) that responds to the user request.
Much of the data will belong to a particular request and so will be local to a servlet method and not vulnerable to multi-threading interference.
Data that must persist throughout a session across several requests must be stored either in a JavaBean associated with a session object or perhaps in a database.
This could apply to the preferences for each user as it is important that users do not accidentally update each others preferences. If stored in a session object then synchronization is not usually needed since each user only has one request active at a time – if this cannot be guaranteed then code that updates the session object should be synchronized.
It is unlikely that instance data or static data will be used, although one possible application would be in keeping track of the number of users online at any given time – updating any such counter variable should be a synchronized operation.
List and discuss three additional issues to consider if we wanted to provide access to the tourist information system from mobile devices such as phones or PDAs.
Three possible issues that arise are:
- *Limited resources** on phones/PDAs - because of the smaller screen space and other resources, the web tier and client tier would need to allow for different formatting of the interface – for example as a WAP interface rather than a standard web browser, or perhaps an application client or applet interface
- *Communication bandwidth** may be limited or more unreliable than with fixed network connections – as above this may require a different interface (less complex maps for example) and emphasises the need for transactions etc to cope with intermittent communications failure.
- *Security issues** - interception of mobile communications is, in principle, easier than for fixed lines. For most transactions on this site security would probably not be a major issue, but when booking accommodation the payment process must be secure.
