- Implemented PostgreSQL persistence
Still missing is the xml persistence implementation and fixing
the tests. Currently no tests were run, just trying to fix compile
errors
- execption handling is done in the ComponentContainerStateHandler
- clients now not need to worry about exceptions which would make them
rethrow anyhow as a runtime exception
Now a SystemUserAction is defined as follows:
<Privilege name="ch.eitchnet.privilege.handler.SystemUserAction"
policy="DefaultPrivilege">
<Allow>li.strolch.agent.impl.StartRealms</Allow>
</Privilege>
This can be very handy to not start the connection pool for realms which
you know won't connect to the DB (but is not transient) - weird isn't
it? =))
The property is: db.ignore.realm.<realmName>
The actual use case is the following:
- You have a realm which use is used normally and is not transient so
you have a configuration for it
- you have another StrolchComponent which opens its own transactions to
the DB but you only require a subset of the realms so you then use the
ignore property to ignore the other realms.
- 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
- Now we can use Version to see if current version is greater than
- Fixed bug where version checking didn't check for app
- TODO is still open to handle migration with intermediary steps
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