Opción para borrar última operación insertada
Sí es cierto que tengo un problema sobre la pregunta que te planteé hace unos días acerca de cómo implementar una opción para borrar la última operación insertada.
Lo del simulador no me ha dado problemas, pero me he dado cuenta al ponerme con esto otro más detenidamente que no puedo hacer un rollback como me sugeriste porque yo siempre cierro la conexión. Mi forma de trabajar conn las conexiones a la base de datos es esta:
...
try {
conn = MySQLDAOFactory.getConnection();
conn.setAutoCommit(false);
// Componemos la sentencia SQL
String query = "UPDATE cartera SET entidad_gest = ? WHERE (id_usuario = ? AND id_cartera = ?)";
prepStat = conn.prepareStatement(query);
// Pasamos los parámetros a la sentencia
prepStat.setString(1, entGest);
prepStat.setString(2, idUsuar);
prepStat.setString(3, idCart);
// Ejecutamos la sentencia, actualizando la entidad gestora
prepStat.executeUpdate();
// Materializamos la sentencia en la base de datos
conn.commit();
} catch (Exception e) {
/* Fallo irrecuperable. Lanzo "RuntimeException"
Deshago cualquier cambio realizado en la base de datos */
try {
conn.rollback();
} catch (Exception e2) {
logg.warn("Excepción al ejecutar 'rollback'", e2);
}
throw new RuntimeException("Se ha producido un error en el acceso a la base de datos", e);
} finally {
MySQLDAOFactory.closeAll(conn, prepStat); // Cerramos conexión y sentencia
}
Como ves, abro y cierro la conexión porque creo que es más eficiente así, y el rollback sólo lo uso por si se producen excepciones. Con esta forma de trabajar con la base de datos no hay ninguna posibilidad de borrar la última operación insertada como me sugeriste. Lo único que se me ocurre es utilizar otra sentencia sql para borrar la tupla de la base de datos cuando el usuario lo solicite, pero no sé si esta es una forma habitual de hacer esto. Igual incluso debería limitar el borrado de este tipo a un par de operaciones solamente, para que no se pueda estar continuamente (si el usuario lo provoca) borrando tuplas ya insertadas. ¿Qué opinas?
Otra cosa más. No he hecho uso aún del "synchronized" en la
aplicación y creo que debería hacerlo, ¿no? ¿Dónde debo hacerlo y cómo?
Lo del simulador no me ha dado problemas, pero me he dado cuenta al ponerme con esto otro más detenidamente que no puedo hacer un rollback como me sugeriste porque yo siempre cierro la conexión. Mi forma de trabajar conn las conexiones a la base de datos es esta:
...
try {
conn = MySQLDAOFactory.getConnection();
conn.setAutoCommit(false);
// Componemos la sentencia SQL
String query = "UPDATE cartera SET entidad_gest = ? WHERE (id_usuario = ? AND id_cartera = ?)";
prepStat = conn.prepareStatement(query);
// Pasamos los parámetros a la sentencia
prepStat.setString(1, entGest);
prepStat.setString(2, idUsuar);
prepStat.setString(3, idCart);
// Ejecutamos la sentencia, actualizando la entidad gestora
prepStat.executeUpdate();
// Materializamos la sentencia en la base de datos
conn.commit();
} catch (Exception e) {
/* Fallo irrecuperable. Lanzo "RuntimeException"
Deshago cualquier cambio realizado en la base de datos */
try {
conn.rollback();
} catch (Exception e2) {
logg.warn("Excepción al ejecutar 'rollback'", e2);
}
throw new RuntimeException("Se ha producido un error en el acceso a la base de datos", e);
} finally {
MySQLDAOFactory.closeAll(conn, prepStat); // Cerramos conexión y sentencia
}
Como ves, abro y cierro la conexión porque creo que es más eficiente así, y el rollback sólo lo uso por si se producen excepciones. Con esta forma de trabajar con la base de datos no hay ninguna posibilidad de borrar la última operación insertada como me sugeriste. Lo único que se me ocurre es utilizar otra sentencia sql para borrar la tupla de la base de datos cuando el usuario lo solicite, pero no sé si esta es una forma habitual de hacer esto. Igual incluso debería limitar el borrado de este tipo a un par de operaciones solamente, para que no se pueda estar continuamente (si el usuario lo provoca) borrando tuplas ya insertadas. ¿Qué opinas?
Otra cosa más. No he hecho uso aún del "synchronized" en la
aplicación y creo que debería hacerlo, ¿no? ¿Dónde debo hacerlo y cómo?
1 respuesta
Respuesta de jruben
1
Pues el caso es que la mejor forma de trabajar es si el usuario se arrepiente de una acción en la base de datos, debería hacer lo contrario, es decir, si inserta, y no lo quiere, lo tiene que borrar, puesto que, como tu dices, si cierras la conexión, ya no puedes echar para atrás, por lo que le deberías dar al usuario los avisos pertinentes y la posibilidad de borrar o cambiar las ultimas acciones.
Por otro lado, no necesitas hacer uso del Synchronized, ¿para qué lo quieres?
Por otro lado, no necesitas hacer uso del Synchronized, ¿para qué lo quieres?
Y en el caso de que un usuario se arrepienta de una acción en la base de datos como tú dices, que es lo que quería decirte desde el principio, y puesto que no se puede hacer un rollback porque la conexión ya está cerrada, ¿cómo se ofrece esa posibilidad de borrar las últimas acciones? ¿Cómo se suele hacer? Manualmente no lo veo viable más que nada porque si al insertar una tupla se desencadenó un trigger, el eliminar la tupla no elimina aquello que produjo el trigger. He visto que hay unas sentencias setSavepoint() y rollback(savepoint). ¿Es esto lo que se utiliza? ¿Esto deshace aquello que pudo hacer algún trigger?
Sobre synchronized, es algo general para la aplicación. No sé si el acceso a las conexiones que te sirve el pool deben ser sincronizadas, quizá las variables almacenadas en el contexto de la aplicación sí que necesiten acceso sincronizado, ... ¿Qué suele sincronizarse en una aplicación? Sé el cómo sincronizar, pero no tengo nada claro qué métodos de mi aplicación definir como syncrhonized.
Gracias por tu ayuda y saludos
Sobre synchronized, es algo general para la aplicación. No sé si el acceso a las conexiones que te sirve el pool deben ser sincronizadas, quizá las variables almacenadas en el contexto de la aplicación sí que necesiten acceso sincronizado, ... ¿Qué suele sincronizarse en una aplicación? Sé el cómo sincronizar, pero no tengo nada claro qué métodos de mi aplicación definir como syncrhonized.
Gracias por tu ayuda y saludos
Puedes probar con setSavePoint, pero no se hasta que punto puede liar la cosa. Yo creo que lo más factible es que el usuario deshaga lo que ha hechop mediante una nueva query.
Todo lo relacionado con synchronize esta versado en la utilización de hilos de ejecución, que no es nuestro caso. El propio pool se encarga de gestionar las conexiones y el acceso a las sesiones de los usuarios, con lo que no nos tenemos que preocupar
Todo lo relacionado con synchronize esta versado en la utilización de hilos de ejecución, que no es nuestro caso. El propio pool se encarga de gestionar las conexiones y el acceso a las sesiones de los usuarios, con lo que no nos tenemos que preocupar
Desharé los cambios con una nueva query como me aconsejas, pero espero que los posibles cambios con triggers pueda también deshacerlos sin demasiados problemas.
Sobre synchronize, podía suponer que el pool haría lo que fuese por mí, pero... ¿y las variables de contexto? ¿Qué sucede si 2 o más usuarios tratan de acceder a una misma variable en el mismo instante de tiempo? ¿No hay que sincronizar en estos casos? Con variables de sesión ya no es necesario, ¿verdad?, puesto que cada usuario tiene las suyas propias aunque el nombre de la variable sea el mismo, ¿no?
Gracias
Sobre synchronize, podía suponer que el pool haría lo que fuese por mí, pero... ¿y las variables de contexto? ¿Qué sucede si 2 o más usuarios tratan de acceder a una misma variable en el mismo instante de tiempo? ¿No hay que sincronizar en estos casos? Con variables de sesión ya no es necesario, ¿verdad?, puesto que cada usuario tiene las suyas propias aunque el nombre de la variable sea el mismo, ¿no?
Gracias
No hay problemas porque todas las variables dependen del objeto session, y como cada usuario tiene un objeto session diferente, no hay por que preocuparse.
