Digamos que tengo una aplicación de escritorio que actúa como un garaje para un montón de coches:Múltiples Hilos para acceder a la base de datos: uno con una larga operación, uno con transacciones cortas
@Entity
public class Garage {
private List<Car> cars = new ArrayList<Car>();
...
}
La aplicación de escritorio tiene una "simulación "botón que inicia un nuevo hilo y comienza a llamar a los métodos en el garaje, coche, rueda, etc. Esta simulación puede tardar hasta 10 minutos en ejecutarse. Por el momento tengo una clase que tiene este aspecto:
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();
Este código sólo lo hace "lee" y nunca "escribe"
Así que lo anterior puede llevar mucho tiempo, dependiendo de lo mal que los coches necesitan un servicio. Mientras sucede lo anterior, el usuario puede continuar trabajando con la aplicación de escritorio. Pueden elegir cambiar el color de un automóvil que se está utilizando en la transacción anterior.
Mi pregunta es si la transacción larga anterior va a evitar el cambio del color del automóvil? es decir, ¿el usuario que cambia el color del automóvil en la aplicación de escritorio no podrá confirmar el cambio hasta que finalice la transacción larga?
¿Por qué necesita una transacción para leer? ¿Estás usando la recuperación perezosa? – saugata
¿Debe el 'hilo de actualización' ser una sola unidad transaccional? ¿O no hay actualizaciones? Usted dice "Este código solo 'lee' y nunca 'escribe'. Entonces - al igual que saugata preguntó - ¿por qué necesita transacciones? –
sí, los métodos que se llaman en un automóvil podrían ser algo así como getWheels() y están siendo perezosamente obtenido – digiarnie