Let's say I have a desktop app that acts as a garage for a bunch of cars:
@Entity
public class Garage {
private List<Car> cars = new ArrayList<Car>();
...
}
The desktop app has a "simulation" button that starts a new thread and starts calling methods on the Garage, Car, Wheel, etc etc. This simulation can take as long as 10 minutes to run. At the moment I have a class that looks like this:
beginTransaction();
Garage garage = garageDao.findGarage(1);
List<Car> cars = garage.getCars();
for (Car car : cars) {
// call methods on the car to lazily fetch other things like wheels...
}
commitTransaction();
This code only does "reads" and never "writes"
So the above can take a long time depending on how badly the cars need a service. While the above is happening, the user may continue working using the desktop app. They may choose to change the color of a car that is being used in the above transaction.
My question is whether the above long transaction is going to prevent the changing of the car color? i.e. the user changing the color of the car in the desktop app will be prevented from committing the change until the long transaction is finished?
Why should it? You're, by default, using optimistic transactions, so there is no locking to be applied to rows being read (unless you're not showing us some JPA2 lock() calls). Commit of the transaction should then check on optimistic version of the records (if you have a version defined) and use that to decide whether to commit the changes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With