- Now if you need to perform commands to carry on in your transaction,
you can simply use the tx.flush()-method.
- Should something go wrong, then even after a tx.flush() one can call
throw tx.fail("Reason") or tx.rollbackOnClose()
- So sadly just auto closing a TX using try-resource from Java7 is a bad idea.
- Doing that leads to problems when an exception is thrown, then the close is called (duh) but this leads to commit being called.
- Since the Java language does not offer a decent way to detect if the close is being called in the context of an exception i was forced to add a tx.commitOnClose() and tx.rollbackOnClose().
- The default is that when a TX is opened, then the close strategy is rollback; the API user must call tx.commitOnClose() before the TX is closed by the braces, or as late as possible, to make sure that if an exception is thrown the transaction is rolled back, and not committed.
- The API was also extended with a tx.fail(msg):StrolchTransactionException so that if the implementor detects an unrecoverable error, one can write: throw tx.fail(“my reason”);
This was sadly an unavoidable late 1.0.0 change
Conflicts:
li.strolch.agent/src/main/java/li/strolch/persistence/api/AbstractTransaction.java
- So sadly just auto closing a TX using try-resource from Java7 is a bad idea.
- Doing that leads to problems when an exception is thrown, then the close is called (duh) but this leads to commit being called.
- Since the Java language does not offer a decent way to detect if the close is being called in the context of an exception i was forced to add a tx.commitOnClose() and tx.rollbackOnClose().
- The default is that when a TX is opened, then the close strategy is rollback; the API user must call tx.commitOnClose() before the TX is closed by the braces, or as late as possible, to make sure that if an exception is thrown the transaction is rolled back, and not committed.
- The API was also extended with a tx.fail(msg):StrolchTransactionException so that if the implementor detects an unrecoverable error, one can write: throw tx.fail(“my reason”);
This was sadly an unavoidable late 1.0.0 change
- this was a big issue as the query was delegated by the TX to the
persistence handler, which meant that the current element map types
(cached, transactional, etc.) were ignored. Move the doQuery to the
element maps, and this lead to also reimplementing the way the cached
element maps work: they now use an in memory dao, instead of MapOfMaps
Now if you add the DefaultServiceHandler property 'throwOnPrivilegeFail'
and set it to true, then the service handler will throw a
StrolchAccessDeniedException which in combination with the
StrolchRestfulExceptionMapper allows rest services to quickly determine
if the error was because the user does not have access to the requested
resource.
Same goes for performing queries in AbstractTransaction only there
instead of throwing a privilege exception, we now also throw a
StrolchAccessDeniedException
When a TX is closed, all locked objects are unlocked. The but originated from multiple commands being performed for the same object, thus the object was locked multiple times i.e. the lock counter was >1. Now added a releaseLock() method which is called by the TX when the TX is closed so that the lock counter is really 0 and the lock is released.
- Added tests for this situation
- documented the LockHandler
SessionHandler now has a timer checking to make sure that sessions which haven’t been accessed for a time defined by ‘session.ttl.minutes’ are invalidated
Now PostgreSQL implementation can import a configured dataStore if the persistence handler configuration property ‘allowDataInitOnSchemaCreate’. For this to work, the schema must have a migration status of CREATED, or DROPPED_CREATED on startup, or using the new method PersistenceHandler.performDbInitialization()-method. Further the properties ‘allowSchemaDrop’ and ‘allowSchemaCreate’ must be enabled.
Robert von Burg
Reto Breitenmoser