Releases: JULIELab/costosys
v1.2.2
v1.2.1
Concurrency issues where observed in v1.2.0 were connections were closed that are still in use in another place. While this can in theory be solved by the calling code, two small adjustments have been made in the hope to avoid the observed errors:
- Iterators obtain connections for the main thread but close them in their own thread. They now close their connections more quickly so they won't be picked up by other code and then get closed so the other code will throw an error.
- When obtaining a connection, now always the newest connection is returned. This ensured more control about which connection is passed to methods following a connection reservation call.
v1.2.0
This release has completely refactored connection management. The recommended method to obtain a connection is now obtainOrReserveConnection() which will return an object of type CoStoSysConnection. This object is just a small wrapper around the actual Connection object and the information whether a new reservation was necessary or an already reserved connection is being reused. This is important when releasing the connection: We don't want to release an obtained connection that is still used by an algorithm in another scope.
To safely release such connections, use the method releaseConnection(CoStoSysConnection). It will only close the connection if the respective connection was newly reserved but the corresponding call to obtainOrReserveConnection(). Note that the CoStoSysConnection class is AutoClosable. Thus, the recommended use is the try(CoStoSysConnection cstsConn = dbc.obtainOrReserveConnection) {...} pattern.
Another major update in this release is the MEDLINE update method (-um parameter in the CLI). This is not just the already known XML update mechanism but is specifically designed for the PubMed/MEDLINE update files obtained from the NCBI FTP server. A dedicated database table is created that keeps track of which update file has when been applied to the MEDLINE data table in the database. Since the update files also specify deletions of documents, this release also contains the functionality to remove such documents from the database and even an ElasticSearch index. The deletion functionality has not yet been tested but may work just fine.
v1.1.3
This release fixes an issue with concurrency deadlocks when trying to obtain connections by multiple threads. However, it is already known that there are more issues. Beginning with v1.2.0, there will be a connection reservation system that should resolve the issue. The problem is that a lot of methods obtain connections on their own. Even when they release them quickly this can lead to a thread waiting on itself to finish with a connection it holds because it is trying to obtain another one. When two threads are doing this and the connection pool is empty, there is a deadlock.
v1.1.2
Fixed issues introduced in the v1.1.0 release concerning the iterators taking a connection as argument. This could cause NPEs in the case when no connection was given. The intended release 1.1.1 only fixed this incompletly, thus the omission of 1.1.1 in the release list.
v1.1.0
This release adds support for the Postgres XML type. This does just mean that the XML type may now be specified in table schemas, there is no particular support for querying such data built into CoStoSys.
Fixed a bug when delivering a non-default, schema-qualified data table in the configuration wouldn't work properly.
The database iterators can now be given an external connection to use. This may lower the requirements on the number of connections from the pool. For example, querying subset tables did not work with only a single connection in the connection pool. This does work now.