Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Multiple Threads accessing the database: one with long transaction, one with short transactions

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?

like image 291
digiarnie Avatar asked Oct 14 '22 19:10

digiarnie


1 Answers

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.

like image 170
DataNucleus Avatar answered Nov 15 '22 07:11

DataNucleus