Changes between Version 2 and Version 3 of AdvancedApplicationDevelopment


Ignore:
Timestamp:
07/03/26 14:34:46 (7 days ago)
Author:
223091
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • AdvancedApplicationDevelopment

    v2 v3  
    55The prototype was extended in two main directions:
    66
    7 * multi-operation database transactions were added for scenarios where several related database changes must be executed as one unit of work;
    8 * database connection pooling was added using HikariCP, so the application does not create a new database connection manually for every operation.
     7* database connection pooling was implemented using HikariCP;
     8* explicit transaction handling was added for use-cases that execute multiple related database operations.
    99
    1010The implementation affects the following source files:
    … …  
    2020=== Description ===
    2121
    22 In the previous prototype version, the application used a direct JDBC connection. In Phase P8, the application was changed to use a database connection pool.
    23 
    24 Connection pooling is useful because database connections are expensive to create and close repeatedly. Instead of creating a new physical connection for every database operation, the application initializes a pool of reusable connections. The application then requests a connection from the pool, uses it for the current operation, and returns it to the pool automatically when the operation finishes.
     22In the previous version of the prototype, the application used a direct JDBC connection. In Phase P8, the application was changed to use a database connection pool.
     23
     24Connection pooling is useful because database connections are expensive to create repeatedly. Instead of creating a new physical database connection for every operation, the application initializes a pool of reusable connections. When a use-case needs database access, the application requests a connection from the pool, uses it, and then returns it to the pool.
    2525
    2626The connection pool is implemented in the class:
    … …  
    3030}}}
    3131
    32 The application initializes the pool after the user enters the database URL, database username, and database password. The pool is then used by the main application class when executing the implemented use-cases.
     32The Maven configuration file ''pom.xml'' was also updated with the required HikariCP dependency.
    3333
    3434=== Implementation ===
    3535
    36 The application uses HikariCP as the connection pooling library. The dependency is included in the Maven configuration file ''pom.xml''.
    37 
    38 The pool is initialized with the database connection parameters and a pool name. The console output confirms that the pool is started successfully.
     36The application initializes the connection pool after the user enters the database URL, database username, and database password. If the pool is created successfully, the application displays a confirmation message and then shows the main menu.
    3937
    4038[[Image(p8_connection_pool_initialized.png, width=100%)]]
    4139
    42 The important result shown in the screenshot is that the application no longer connects only through a single direct JDBC connection. Instead, it initializes the connection pool first and then successfully connects to the database.
    43 
    44 The application displays:
     40The screenshot shows that the HikariCP connection pool starts successfully. The application then confirms that the database connection pool was initialized and that the database connection is successful.
     41
     42The important confirmation messages are:
    4543
    4644{{{
    … …  
    5048}}}
    5149
    52 After the pool is initialized, the main menu is displayed:
     50After the connection pool is initialized, the application displays the main menu:
    5351
    5452{{{
    … …  
    6462=== Usage in the application ===
    6563
    66 The application uses connections from the pool when executing database operations. The connection is obtained from the pool, used inside the selected use-case, and then closed in the Java code. Closing the connection does not close the physical database connection immediately; it returns the connection to the pool so that it can be reused.
    67 
    68 This is used in the implemented use-cases:
    69 
    70 * ''Search available rooms''
     64The application uses connections from the pool in the implemented use-cases. A connection is requested from the pool before executing SQL statements. When the operation finishes, the connection is closed in the Java code, but this does not destroy the physical database connection. Instead, the connection is returned to the pool and can be reused.
     65
     66This improves the structure of the application because database access is managed through a separate pooling class instead of being handled manually in every part of the application.
     67
     68== Transactions ==
     69
     70Transactions are required when one logical operation contains multiple database operations that must succeed or fail together.
     71
     72In this prototype, transactions are used in the following implemented use-cases:
     73
    7174* ''Create reservation request''
    7275* ''Approve or reject reservation''
    7376
    74 == Transactions ==
    75 
    76 Transactions are needed when one logical application operation modifies multiple related database tables. If one part of the operation succeeds and another part fails, the database must not remain in a partially modified state.
    77 
    78 The Java application therefore uses explicit transaction control for the use-cases where several related database operations are executed together.
    79 
    80 The transaction logic follows this structure:
     77The application uses explicit transaction control in Java. The general transaction structure is:
    8178
    8279{{{
    … …  
    9491}}}
    9592
    96 This means that all database changes inside the transaction are saved only if the whole operation is successful. If an error occurs, all changes from that transaction are rolled back.
     93This means that all database changes inside the transaction are saved only if the complete operation is successful. If an error occurs, the transaction is rolled back and the database is not left in a partially modified state.
    9794
    9895== Transaction 1: Create reservation request ==
    … …  
    10097=== Data requirements description ===
    10198
    102 Creating a reservation request can require changes in more than one table.
    103 
    104 A reservation request may include:
     99Creating a reservation request may require changes in more than one table.
     100
     101A reservation request can include:
    105102
    106103* only a room;
    … …  
    108105* both a room and requested equipment.
    109106
    110 When the requester creates a reservation with additional equipment, the application must insert a new record into:
     107When the requester creates a reservation with additional equipment, the application must insert data into:
    111108
    112109* ''project.reservations''
    113 
    114 and then insert one or more related records into:
    115 
    116110* ''project.reservation_equipment''
    117111
    118 These operations must be executed in one transaction. If the reservation is inserted successfully, but the equipment insert fails, the whole operation must be rolled back. Otherwise, the database could contain an incomplete reservation.
     112These operations must be executed as one transaction. If the reservation is inserted but inserting the requested equipment fails, the whole operation should be rolled back. This prevents incomplete reservation data from being saved.
    119113
    120114=== Implementation ===
    … …  
    124118The application performs the following steps:
    125119
    126 1. The requester is selected from the displayed list of users.
    127 2. The reservation date, start time, and end time are entered.
    128 3. The requester chooses whether the reservation includes a room.
    129 4. If a room is included, the application displays available rooms and the requester selects one of them.
    130 5. The requester chooses whether additional/general equipment should be requested.
    131 6. If equipment is requested, the application displays available equipment and the requester selects equipment items and quantities.
    132 7. The application starts a transaction.
    133 8. The application inserts the reservation into ''project.reservations''.
    134 9. If requested equipment exists, the application inserts the related rows into ''project.reservation_equipment''.
    135 10. If all SQL statements are successful, the transaction is committed.
    136 11. If any SQL statement fails, the transaction is rolled back.
     1201. The requester chooses the option ''Create reservation request'' from the main menu.
     1212. The system displays a list of users.
     1223. The requester selects the requester from the list.
     1234. The system asks for the reservation date.
     1245. The requester enters the reservation date.
     1256. The system asks for the start time and end time.
     1267. The requester enters the requested time interval.
     1278. The system asks whether the reservation should include a room.
     1289. If the reservation includes a room, the system displays available rooms.
     12910. The requester selects one of the available rooms from the list.
     13011. The system asks whether additional/general equipment should be requested.
     13112. If equipment is requested, the requester selects equipment and requested quantity.
     13213. The application starts a transaction.
     13314. The application inserts a new record into ''project.reservations''.
     13415. If requested equipment exists, the application inserts corresponding records into ''project.reservation_equipment''.
     13516. If all operations are successful, the transaction is committed.
     13617. If an error occurs, the transaction is rolled back.
    137137
    138138=== Demo execution ===
    139139
    140 The following screenshot shows the creation of a reservation request with additional equipment.
     140The following screenshot shows the successful execution of the create reservation transaction.
    141141
    142142[[Image(p8_create_reservation_transaction_success.png, width=100%)]]
    143143
    144 In this test, the requester creates a reservation for room ''LAB-1'' on ''2026-06-01'' from ''09:00'' to ''10:00'' and additionally requests ''HDMI Cable''.
    145 
    146 The following screenshot shows that the reservation request was created successfully.
    147 
    148 [[Image(p8_transaction_create_reservation_success.png, width=100%)]]
    149 
    150 The application displays the generated reservation ID and the created reservation details.
     144In this test, the requester creates a reservation request through the Java prototype. The application displays available users and rooms, the requester selects values from the displayed lists, and the reservation request is created successfully.
     145
     146The use-case demonstrates that the user does not need to remember internal database identifiers such as ''user_id'' or ''room_id''. Instead, the application lists the possible values and internally uses the selected database identifiers.
    151147
    152148=== Database verification ===
    153149
    154 The result can be verified in DBeaver by checking the base tables.
     150The result can be verified in DBeaver by checking the created reservation and the requested equipment records.
    155151
    156152{{{
    … …  
    164160}}}
    165161
    166 The following screenshot shows that the reservation was inserted into ''project.reservations'' and that the requested equipment was inserted into ''project.reservation_equipment''.
    167 
    168 [[Image(p8_transaction_create_reservation_db_verification.png, width=100%)]]
     162The following screenshot shows the database verification after the transaction was executed.
     163
     164[[Image(p8_create_reservation_database_verification.png, width=100%)]]
     165
     166The screenshot confirms that the reservation was inserted into ''project.reservations''. If the reservation included additional requested equipment, the related records are also inserted into ''project.reservation_equipment''.
    169167
    170168=== Transaction discussion ===
    171169
    172 This operation is a transaction because the reservation and the requested equipment represent one logical request. The database should not contain requested equipment without the corresponding reservation, and it should not contain a partially created reservation if the equipment insert fails.
     170This use-case requires a transaction because creating a reservation request is one logical operation, even when it modifies multiple tables. The reservation and its requested equipment must be saved together. If one part fails, the whole operation should be cancelled.
    173171
    174172Therefore, the application commits the transaction only after all related inserts are successful.
    … …  
    178176=== Data requirements description ===
    179177
    180 Approving or rejecting a reservation also requires more than one database change.
     178Approving or rejecting a reservation also requires multiple related database operations.
    181179
    182180When an approver makes a decision, the application must:
    183181
    184 * update the status of the selected reservation in ''project.reservations'';
    185 * insert the approval decision into ''project.approvals''.
    186 
    187 These two operations must be executed consistently. The reservation status and the approval record must always match. If the approval record cannot be inserted, the reservation status should not remain changed.
     182* update the reservation status in ''project.reservations'';
     183* insert a new approval decision into ''project.approvals''.
     184
     185These two operations must be consistent. The reservation status and the approval record must match. If the approval record cannot be inserted, the reservation status should not remain changed.
    188186
    189187=== Implementation ===
    … …  
    193191The application performs the following steps:
    194192
    195 1. The approver opens the ''Approve or reject reservation'' option from the main menu.
    196 2. The application lists all pending reservations.
    197 3. The approver selects a reservation from the displayed list.
    198 4. The application lists users who are allowed to approve reservations.
     1931. The approver chooses the option ''Approve or reject reservation'' from the main menu.
     1942. The system displays a list of pending reservations.
     1953. The approver selects one reservation from the list.
     1964. The system displays a list of users who can approve reservations.
    1991975. The approver selects the approving user.
    200 6. The approver chooses either ''approved'' or ''rejected''.
     1986. The approver chooses whether the reservation should be approved or rejected.
    2011997. The approver enters an optional decision note.
    2022008. The application starts a transaction.
    203 9. The application updates the reservation status in ''project.reservations''.
     2019. The application updates the selected reservation status in ''project.reservations''.
    20420210. The application inserts a new approval record into ''project.approvals''.
    20520311. If both operations are successful, the transaction is committed.
    … …  
    208206=== Demo execution ===
    209207
    210 The following screenshot shows the approval process in the Java prototype.
    211 
    212 [[Image(p8_transaction_approve_reservation_input.png, width=100%)]]
    213 
    214 The approver selects a pending reservation, selects the approving user, chooses the decision, and enters the decision note.
    215 
    216 The following screenshot shows the successful result of the approval transaction.
    217 
    218 [[Image(p8_transaction_approve_reservation_success.png, width=100%)]]
    219 
    220 The application displays the final reservation details, including the updated status, decision, decision time, and approver.
     208The following screenshot shows the successful execution of the approval transaction.
     209
     210[[Image(p8_approval_transaction_success.png, width=100%)]]
     211
     212The screenshot shows that the approver selects a pending reservation, chooses the approver user, enters the decision, and saves the approval decision. The application then displays the final reservation details.
    221213
    222214=== Database verification ===
    … …  
    234226}}}
    235227
    236 The following screenshot shows that the reservation status was updated and that the corresponding approval record was inserted.
    237 
    238 [[Image(p8_transaction_approve_reservation_db_verification.png, width=100%)]]
     228The following screenshot shows the database verification after the approval transaction was executed.
     229
     230[[Image(p8_approval_database_verification.png, width=100%)]]
     231
     232The screenshot confirms that the reservation status was updated and that a corresponding approval record was inserted into ''project.approvals''.
    239233
    240234=== Transaction discussion ===
    241235
    242 This operation is a transaction because approval is not just one table change. The reservation status and approval decision must be saved together. If only the reservation status were updated without inserting an approval record, the database would lose information about who made the decision and when it was made.
    243 
    244 Therefore, the application treats the approval operation as one atomic unit of work.
     236This use-case requires a transaction because approval is not only a single table change. The status update and the approval insert represent one logical decision.
     237
     238If the reservation status were updated without inserting an approval record, the database would lose information about who made the decision, when the decision was made, and what note was entered. Therefore, both operations must be committed together or rolled back together.
    245239
    246240== Rollback behavior ==
    247241
    248 The transaction implementation also protects the database from partial changes. If an error happens during a transaction, the application executes rollback.
    249 
    250 For example, in the create reservation transaction, if the reservation insert succeeds but a related requested equipment insert fails, the reservation should not remain saved as an incomplete request. Similarly, in the approval transaction, if the reservation status update succeeds but the approval insert fails, the status update should be rolled back.
    251 
    252 This behavior is important because it preserves database consistency.
    253 
    254 [[Image(p8_transaction_rollback_test.png, width=100%)]]
    255 
    256 The screenshot above demonstrates that an invalid or failing operation does not leave incomplete data in the database.
     242The transaction implementation protects the database from partial changes.
     243
     244If an error occurs during the create reservation transaction, the inserted reservation and related requested equipment records are rolled back. If an error occurs during the approval transaction, the reservation status update and the approval insert are rolled back.
     245
     246This behavior preserves database consistency because incomplete multi-step operations are not saved.
    257247
    258248== Maven configuration ==
    259249
    260 The Maven configuration file ''pom.xml'' was updated to include the required dependencies for PostgreSQL JDBC and HikariCP.
    261 
    262 The PostgreSQL JDBC driver is required so the Java application can connect to the PostgreSQL database.
    263 
    264 HikariCP is required so the application can use database connection pooling.
     250The Maven configuration file ''pom.xml'' was updated to include the required dependencies.
     251
     252The application uses:
     253
     254* PostgreSQL JDBC driver for connecting to the PostgreSQL database;
     255* HikariCP for database connection pooling;
     256* SLF4J implementation for HikariCP logging.
    265257
    266258The relevant configuration is stored in:
    … …  
    272264== Final discussion ==
    273265
    274 Phase P8 improves the Java prototype by adding application-level transaction handling and database connection pooling.
     266Phase P8 improves the Java prototype by adding transaction handling and database connection pooling.
    275267
    276268The most important improvements are:
    277269
    278 * the application uses a reusable connection pool instead of relying on a single direct JDBC connection;
    279 * the connection pool is initialized once and then reused by the implemented use-cases;
     270* the application uses HikariCP connection pooling;
     271* database access is centralized through ''DatabasePool.java'';
     272* the connection pool is initialized once and reused by the application;
    280273* creating a reservation request is executed as a transaction;
    281 * inserting requested equipment for a reservation is included in the same transaction as the reservation insert;
     274* inserting requested equipment is included in the same transaction as the reservation insert;
    282275* approving or rejecting a reservation is executed as a transaction;
    283 * reservation status updates and approval record inserts are saved together;
    284 * rollback is used when a multi-step operation fails;
    285 * database consistency is preserved even when a use-case requires several SQL statements.
    286 
    287 These improvements make the prototype more reliable and closer to a real database application, while still keeping the application intentionally simple for the project phase.
     276* reservation status updates and approval records are saved consistently;
     277* rollback is used when a multi-step database operation fails;
     278* the prototype is more reliable and closer to a real database application.
     279
     280These additions satisfy the Phase P8 requirements because the application now demonstrates both database connection pooling and transactions for use-cases where multiple related database operations must be executed as one unit of work.