Daniel Camacho
Omar Villada
Juan Marcelo Panasiti
Juan Sebastián Joya Rodríguez
Pablo Andrés Prado Diaz
Cid Emmanuel Esquivel González
Jefry Amador
Sergio Andrés Majé Franco
Daniel Esteban Pérez Bohórquez
Ana Fernanda Gutierrez Villanueva
Ana Fernanda Gutierrez Villanueva
Tara Campos Padilla
Juan Marcelo Panasiti
Isay Humberto Lucas Hernandez
Xavier Armando Larios Alvarenga
Milton Hernan Camacho Quitian
Micael Abdias Rodriguez
Xavier Armando Larios Alvarenga
Juan Ignacio Gonzalez Burnet
Pablo Andrés Prado Diaz
Cid Emmanuel Esquivel González
Fabiola Jacqueline Paz Alatorre
Juan Felipe Barahona Gonzalez
Pedro Nicolas Rios Vargas
Jaime Manuel Cutipa Calderón
Joselyn Pariansullca
Joselyn Pariansullca
Jose Carrillo Zenteno
Joahan Carlo Nuñez Soto
Daniel Esteban Pérez Bohórquez
Jesús Sánchez
Jesús Sánchez
Creo que asi no este dentro de una transaccion, si no se cumple los constraints, igual no guarda
Es verdad, en este caso el ejemplo no fue el mas realista para explicar transacciones.
Claro, el ejemplo quizá no fue lo más ilustrativo.. pero imaginate que, una vez creado el employee tuviera que insertar un registro en otra tabla (o incluso podria ser antes de crear el employee) y la regla del negocio dicta que deben crear se ambas cosas o ninguna (ambos registros en la db).. tratandolo como transacciones atómicas, solo harías el commit si ambas insersiónes son correctas..
Sin usar transacciones atomicas, al momentos de crear correctamente el empleado y que el error se produzca al crear el segundo registro en la otra tabla, entonces terminarías con la tabla de empleados con un nuevo registro y la otra tabla sin su registro nuevo..
El caso de uso no me gusto tanto, porque igualmente sin haber agregado el cambio al código, no se hubiese agregado el registro. Quizas lo interesante seria un ejemplo en donde se tengan varios registros, y no se inserte ninguno si alguno tiene el mismo curp, o un ejemplo en donde el registro se hubiese insertado en la bd si no se hubiera cacheado previamente.
El ejemplo es correcto. Intenta crear dos employee en la misma transacción. Si los dos cumplen todos las reglas de creación se van a crear los dos.
Después dale opciones validas al primer Employee y al segundo indúcelo al error. Puedes repetir el curp como en la clase.
Puedes comprobar listando tu tabla employee después de crear el primer usuario y veras que se crea. Pero como el segundo usuario no es valido veras que mediante el roleBack se elimina tu primer cambio así sea valida su creación.
La regla de la transacción le indica que si alguno de los cambios dentro de la misma transacción no es valido se retorne la BD a su estado previo.
@Andres_Pavel Intenta correr el codigo sin la linea del commit y el rollback junto con algun error en la CURP y veras que tampoco se hace la inserción.
Este fue un ejemplo pésimo, yo vengo de otros lenguaje de programación.
ella no necesitaba commit ni rollback para que se cumpliera ya que al intentar insertar, la base de datos iba a gritar ya que ella le tenia el constrain único (UNIQUE) y el catch iba a devolver el mensaje.
un buen ejemplo seria en una transaccion bancaria donde primero a la cuenta origen vas hacer un update para restar a la cuenta origen y un update para sumer el monto de la transaccion a la cuenta destino.
errores que pude solventar el commit y rollback: 1 si se pierde la conexion en el primer update, no se aplica el commit. 2. si la cuenta destino tiene un bloqueo que no acepta transaccion ya sea porque es una cuenta cancelada o embargada entonces se aplica el commit.
en su explicación ella puede quietar el commit y rollback y como quiera o va a persistir la información.
👎👎👎👎
Para crear una columna llamada curp en una tabla existente en MySQL, puedes usar el siguiente código en MySQL Shell:
ALTER TABLE Employees ADD COLUMN curp VARCHAR(18) UNIQUE;
Este código añade la columna curp de tipo VARCHAR con una longitud máxima de 18 caracteres y la establece como única, lo que significa que no puede haber valores duplicados en esta columna.
Tenemos una clave por cada conexión, pero si son varios usuarios intentando editar la base de datos, ¿habría un problema, no?
Si cada usuario tiene una clave única para su conexión a la base de datos, entonces existen formas de garantizar que las operaciones de edición sean seguras y controladas, incluso si varios usuarios intentan editar la base de datos simultáneamente. En este caso una de ellas son justamente las transacciones son una parte fundamental para garantizar la consistencia de los datos en una base de datos. 🤓
Por ejemplo en un banco cada transacción debe ser administrada de manera independiente. Cuando un usuario inicia una transacción, se debe abrir una conexión de base de datos separada para esa transacción. Esto evita que las transacciones de un usuario interfieran con las de otros.
¡Si! 😃 Para manejar varios usuarios editando la base de datos al mismo tiempo tenemos algunos problemas Comunes 🛠️
Conflictos de Concurrencia:
Bloqueos:
Lecturas Sucias:
++Soluciones y Buenas Prácticas 💡++
Uso de Transacciones:
connection.setAutoCommit(false); // Inicia la transacción try { // Realiza las operaciones en la base de datos String sql = "UPDATE accounts SET balance = balance - ? WHERE account_id = ?"; try (PreparedStatement pstmt = connection.prepareStatement(sql)) { pstmt.setDouble(1, amount); pstmt.setInt(2, accountId); pstmt.executeUpdate(); } connection.commit(); // Confirma los cambios } catch (SQLException e) { connection.rollback(); // Revierte si hay error e.printStackTrace(); }
Control de Concurrencia:
String sql = "UPDATE accounts SET balance = balance - ? WHERE account_id = ? AND version = ?";
String sql = "SELECT * FROM accounts WHERE account_id = ? FOR UPDATE";
Niveles de Aislamiento:
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
Manejo de Errores y Conflictos:
catch (SQLException e) { if (e.getSQLState().equals("23505")) { // Código de error para conflicto de clave única System.out.println("Error: Registro ya existe."); } e.printStackTrace(); }
Yo realice la implementacion en el databaseConection, implemente una funcion para salvar la transaccion y lo llamo desde el front cuando ya tengo todas las transacciones:
Pero es correcto eso? digo, en ese caso el front estaría teniendo conocimiento del estado de las transacciones de la base de datos y creo que eso es solo responsabilidad del back,
Otra forma de controlar las transacciones es con un Stored procedure.
Si todo ok -> COMMIT sino -> ROLLBACK
Qué es CURP?
En este contexto, la CURP es un campo de 18 caracteres que agregamos a la base de datos para identificar a los empleados de forma única. Sirve para practicar restricciones de unicidad y manejo de errores en transacciones con JDBC.
Implementar COMMIT y ROLLBACK en este ejemplo es útil para entender que normalmente cada operación se guarda de forma automática en la BD, dado que se tiene por defecto autoCommit = true, sin embargo, un caso en el que se podría sacar mayor provecho sería cuando se necesita confirmar varias operaciones en una sola unidad lógica, por ejemplo, en una transferencia entre cuentas, en la cuenta A se descuenta, en la cuenta B se abona, estas dos operaciones deben ocurrir juntas, de lo contrario, se podrían presentar problemas como que se descuente pero no se abone.
Hice este ejemplo por mi cuenta para entenderlo:
Main.java
package org.example.main; import org.example.model.Employee; import org.example.repository.EmployeeRepository; import org.example.repository.Repository; import org.example.util.DatabaseConnection; import java.sql.*; public class Main { public static void main(String[] args) throws SQLException { try (Connection myConn = DatabaseConnection.getInstance()) { if (myConn.getAutoCommit()) { myConn.setAutoCommit(false); } Repository<Employee> repository = null; try { repository = new EmployeeRepository(myConn); System.out.println(" ---------- Dar de alta un empleado ------------"); Employee employee = new Employee(); employee.setFirst_name("America"); employee.setPa_surname("Lopez"); employee.setMa_surname("Villa"); employee.setEmail("villa@example.com"); employee.setSalary(300F); employee.setCurp("AMEC234Y91J0LPSDEL"); //no tiene 18 digitos repository.save(employee); System.out.println(" --- Simulamos un error al dar de alta----"); Employee employee2 = new Employee(); employee2.setFirst_name("Martin"); employee2.setPa_surname("Lopez"); employee2.setMa_surname("Lopez"); employee2.setEmail("villa@example.com"); employee2.setSalary(300F); employee2.setCurp("AMEC234Y91J0LPSDEL"); //Tiene mismo curp que el anterior repository.save(employee2); myConn.commit(); } catch (SQLException e) { //Usamos el catch para el rollback System.out.println("Hubo un error. Se volvera al estado anterior"); System.out.println("Como el segundo empleado tiene el mismo curp. Ninguno de los dos" + "se dara de alta"); myConn.rollback(); throw new RuntimeException(e); } } } }
Se crea un constructor en EmployeeRepository para establecer una conexión única a la base de datos utilizando un solo objeto de conexión (myCon). Esto permite que todas las operaciones dentro de las transacciones compartan la misma conexión, garantizando la atomicidad de las transacciones. Así, si alguna operación falla, se puede realizar un rollback, asegurando que la base de datos mantenga su integridad. Esta práctica ayuda a optimizar el uso de recursos y a evitar problemas de rendimiento que podrían surgir al abrir múltiples conexiones.
No sé si soy el único, pero siento que se pierde mucho tiempo cuando va diciendo en voz alta lo que está escribiendo, en lugar de enfocarse más en el por qué de cada cosa. Además, sería útil que explicara mejor los métodos que utiliza. Por ejemplo, en el caso del método rollback(), sería bueno detenerse un momento para explicar en detalle cómo funciona y qué hace. De lo contrario, da la sensación de que solo se está copiando y pegando código sin profundizar en su propósito.
Extendiendo un poco para los que creen que el ejercicio no es el adecuado.
El ejemplo no esta mal. En este caso esta inconclusa la explicación. Básicamente el try donde se hace la creación de un nuevo empleado es una transacción. En ella puedes hacer múltiples peticiones usando una sola conexión. Para que puedas comprobar que el principio atomic se cumple puedes crear dos nuevos empleados en el mismo try, el cual se maneja mediante una sola conexión.
En mi caso estoy creando un Usuario pero pueden replicar el ejemplo usando la clase Employee de la clase:
User user1 = new User();
user1.setNickname("Architect");
user1.setPassword("admin123");
user1.setLogin("logead");
user1.setEmail("correo8@correo.com");
user1.setNickname("DevOps");
User user2 = new User();
user2.setNickname("AWS");
user2.setPassword("admin123");
user2.setLogin("logead");
user2.setEmail("correo8@correo.com");
user2.setNickname("DevOps");
List<User> usersList;
import org.example.joseFrontend.model.User;
import org.example.joseFrontend.repository.Repository;
import org.example.joseFrontend.repository.UserRepository;
import org.example.joseFrontend.util.DatabaseConnection;
import java.sql.*;
import java.util.List;
public class Main {
public static void main(String[] args) throws SQLException {
try(Connection myConn = DatabaseConnection.``getInstance``()){
if(myConn.getAutoCommit()){
myConn.setAutoCommit(false);
}
User user1 = new User();
user1.setNickname("Architect");
user1.setPassword("admin123");
user1.setLogin("logead");
user1.setEmail("correo8@correo.com");
user1.setNickname("DevOps");
User user2 = new User();
user2.setNickname("AWS");
user2.setPassword("admin123");
user2.setLogin("logead");
user2.setEmail("correo8@correo.com");
user2.setNickname("DevOps");
List<User> usersList;
try{
Repository<User> userRepository = new UserRepository(myConn);
System.``out``.println("--------------Antes Cambio 1----------------");
usersList = userRepository.findAll();
usersList.forEach(System.``out``::println);
userRepository.save(user1);
System.``out``.println("--------------Después Cambio 1----------------");
usersList = userRepository.findAll();
usersList.forEach(System.``out``::println);
System.``out``.println("--------------Antes Cambio 2----------------");
userRepository.save(user2);
System.``out``.println("--------------Después Cambio 2----------------");
usersList = userRepository.findAll();
usersList.forEach(System.``out``::println);
System.``out``.println("-------------------------------------");
myConn.commit();
}catch (SQLException exception){
myConn.rollback();
}
}
}
}
@Andres_Pavel Intenta correr el codigo sin la linea del commit y el rollback junto con algun error en la CURP y veras que tampoco se hace la inserción. Por eso varios decimos que este ejemplo no es el mejor...
La clase trata sobre la implementación de transacciones utilizando JDBC en Java. Se explica cómo gestionar transacciones en una base de datos, asegurando que múltiples operaciones se realicen de manera atómica. Se muestran ejemplos prácticos de cómo establecer y manejar conexiones, realizar commits y rollbacks, y cómo agregar nuevos campos a las tablas de la base de datos para mantener la integridad de los datos. Además, se discuten patrones de diseño como DAO y Repository para una gestión de datos más estructurada.
Configurando el autocommit en DatabaseConnection
public class DatabaseConnection { private static final String url = "jdbc:mysql://localhost:3306/project"; private static final String user = "admin"; private static final String pass = "admin123"; private static Connection connection; public static Connection getInstance() throws SQLException { if (connection == null) { connection = DriverManager.getConnection(url, user, pass); connection.setAutoCommit(false); } return connection; } } ```En Main ```js try(Connection connection = DatabaseConnection.getInstance()) { try { IRepository<Employee> employeeRepository = new EmployeeRepository(connection); System.out.println("--- Add new employee ---"); // Adding employee 1 Employee e = new Employee( "Carlangas", "Lanas Rosas", "1234567890" ); boolean done = employeeRepository.save(e); String msg = done ? "Employee created" : "Employee couldn't be created"; System.out.println("--- "+msg+" ---"); // Adding employee 2 Employee e2 = new Employee( "Papilla", "Rosales Candida", "1234567890" ); done = employeeRepository.save(e2); connection.commit(); msg = done ? "Employee created" : "Employee couldn't be created"; System.out.println("--- "+msg+" ---"); } catch (SQLException ex) { connection.rollback(); System.out.println("--- Rollback executed ---"); } } catch (SQLException e) { throw new RuntimeException(e); } ```Obtengo el siguiente resultado ```js --- Add new employee --- --- Employee created --- --- Rollback executed --- Process finished with exit code 0
Hey, si no quieren borrar el paquete view y están usando un entorno como Maven o Gradle les recomiendo agregar lo siguiente.
Maven
Dentro del pom.xml agreguen:
1. \<project> 2.   ... 3.   \<build> 4.   \<pluginManagement> 5.   \<plugins> 6.   \<plugin> 7.   \<groupId>org.apache.maven.plugins\</groupId> 8.   \<artifactId>maven-compiler-plugin\</artifactId> 9.   \<version>3.11.0\</version> 10.   \<configuration> 11.   \<exclude> 12.   \<exclude> 13. \*\*/view/SwingApp.java 14.   \</exclude> 15.   \</excludes> 16.   \</configuration> 17.   \</plugin> 18.   \</plugins> 19.   \</pluginManagement> 20.   \</build> 21.   ... 22. \</project>
Gradle
Dentro del build.gradle agreguen:
// código sourceSets {   main {   java {   exclude '\*\*/view/SwingApp.java'   }   } } // más codigo
Bastaría con poner NULL en la clase:
Para notar el funcinoamiento del rollback podemos realizar 02 consultas de tipo insert (metodo save() ).
public class ``Main {
``public static void ``main(String[] args) ``throws ``SQLException {
``//We create a new employee, we will use it later.
Employee employee03 = ``new ``Employee();
employee03.setFirst_name("luz");
employee03.setPa_surname("clarita");
employee03.setMa_surname("gutarra");
employee03.setEmail("luz@example.com");
employee03.setSalary("50000");
employee03.setCurp("ROSAS1234567891R15");
Employee employee04 = ``new ``Employee();
employee04.setFirst_name("cielo");
employee04.setPa_surname("rosales");
employee04.setMa_surname("contreras");
employee04.setEmail("cielo@example.com");
employee04.setSalary("10000");
employee04.setCurp("ROSAS1234567891R15");
``try``(Connection myConn = DataBaseConnection.getInstance()){
``if``(myConn.getAutoCommit()){
myConn.setAutoCommit(``false``);
}
``try``{
``//We create an instance of EmployeeRepository
``Repository<Employee> employeeRepository = ``new ``EmployeeRepository(myConn);
``//Find all employees and then show them on the console.
``employeeRepository.findAll().forEach(System.out::println);
System.out.println("*********************************************");
``//We do two operations for modify data of the table
//insert (1)
``employeeRepository.save(employee03);
``//Find all employees and We see the change.
``employeeRepository.findAll().forEach(System.out::println);
System.out.println("*********************************************");
``//insert (2)
``employeeRepository.save(employee04);
``//Find all employees and We see the change.
``employeeRepository.findAll().forEach(System.out::println);
} ``catch ``(SQLException e){
myConn.rollback();
``throw new ``RuntimeException();
}
}
}
}
El resultado que obtendremos sera el siguiente:
Aqui podemos ver que el primer listado es antes de realizar el insert, al segunda lista es despues de realizar el primer insert y vemos que si se anadio el registro. Al intentar realizar el segundo insert presenta un error por la duplicidad del 'corp', por lo que entra al catch( ) donde se ejecutar el 'rollback( )'. Si hacemos un SELECT desde nuestra BD o si volvemos a ejecutar el metodo findAll( ) desde el proyecto, veremos que ese registro que se inserto ya fue quitado.
El codigo 😅.
try(Connection myConn= CONECTARBD.getInstance()){ if(myConn.getAutoCommit()){ myConn.setAutoCommit(false); } try{ Repositorio<PERSONA> repositorio =new CNPersona(myConn); System.out.println("----------- Ingreso de una nueva persona----------"); PERSONA persona=new PERSONA(); persona.setNombrePersona("Luis"); persona.setCedulaPersona("0103304531"); repositorio.Almacenar(persona); myConn.commit();
System.out.println("-------- IMPRIMIR TODOS LOS REGISTROS"); repositorio.LeerTodos().forEach(System.out::println);
} catch (SQLException ex) { myConn.rollback(); throw new RuntimeException(ex); }
} catch (SQLException ex) { throw new RuntimeException(ex); }
En mi caso:
public static void main(String[] args) throws SQLException {
try(Connection conn= DataBaseConnection.getInstance()){
if(conn.getAutoCommit()){
conn.setAutoCommit(false);
}
try{
Repository<Employee> repository = new Employee_repository(conn);
System.out.println("....Insertar un nuevo cliente......");
Employee employee = new Employee();
// employee.setFirts_name("Alejandra");
// employee.setPa_surname("Ferrera");
// employee.setMa_surname("Cáceres");
// employee.setEmail("ale@example.com");
// employee.setSalary(3500F);
// employee.setCurp("ALEJ123456741258EC");
// repository.save(employee);
// conn.commit();
employee.setFirts_name("Marco");
employee.setPa_surname("Nuñez");
employee.setMa_surname("Soto");
employee.setEmail("amarco@example.com");
employee.setSalary(3600F);
employee.setCurp("ALEJ123456741258EC");
repository.save(employee);
conn.commit();
}
catch(SQLException e){
conn.rollback();
throw new RuntimeException();
}
Básicamente si creo mas empleados, como podria crear mas, deberia cambiar ese Curl? o ?
Al ser ese campo único en la BD podría primero validar que el CURP del nuevo empleado no existe (select * from employees where CURP = ‘XYZ’). Si el contador te regresa 1 mandar un mensaje de error (CURP existente) y si el contador te regresa 0 entonces insertarlo en la BD.
No es buena practicar esperar a que falle para mandar un mensaje de error lo ideal es siempre validar los datos.
Era un select count 😝 lo siento escribí muy rápido.
