Clarify BucketManagerFactory and BucketManager lifecycles

[rashtao]

Description

As a:

• Application user/user of the configuration itself
• API user (application developer)
• SPI user (container or runtime developer)
• Specification implementer

...I need to be able to:

understand the lifecycle of BucketManagerFactory and BucketManager, in particular:

1. when they should be closed
2. which of the 2 should close the underlying database driver connection

AFAICS, this behavior is not specified in the javadoc and the databases implementations (https://github.com/eclipse/jnosql-databases) do not implement the same behavior. For example, some databases (like Redis, Couchbase, Dynamo, ...) close the driver connection in their implementation of org.eclipse.jnosql.communication.keyvalue.BucketManagerFactory#close(), while some of them (Redis, Dynamo, Riak, ...) also close it in org.eclipse.jnosql.communication.keyvalue.BucketManager#close().

---

Also, the same clarification is needed for lifecycles of DatabaseManagerFactory and DatabaseManager. AFAICS, also here some databases (like Cassandra) close the connection in org.eclipse.jnosql.databases.cassandra.communication.DefaultCassandraColumnManager#close(), while others (like MongoDB) close it in org.eclipse.jnosql.databases.mongodb.communication.MongoDBDocumentManagerFactory#close().

[dearrudam]

Hey @rashtao! Awesome questions, and thanks for bringing them up!

The primary goal of the Eclipse JNoSQL Project is to simplify the integration of Java applications with NoSQL databases. To achieve this, each database implementation (https://github.com/eclipse/jnosql-databases) takes on the responsibility of managing the connection lifecycle for the respective database driver it supports.

This approach is necessary because connection strategies differ significantly across database vendors. As a result, each JNoSQL implementation must handle the unique requirements of the driver it supports.

The decision to manage the database driver connection lifecycle has presented and continues to present challenges. Each database implementation must align with the specific connection management practices of the vendor it supports.

For instance, NoSQL database vendors often offer multiple ways to establish and manage connections. Redis, for example, supports several modes: cluster mode, master-slave mode, sentinel mode, and even combinations of these modes. Handling such diverse connection strategies within JNoSQL implementations adds considerable complexity.

Trying to support all these options in JNoSQL implementations is no small feat! Each implementation has to create and handle specific properties needed to set up and manage those connections properly. And since JNoSQL takes care of setting up the driver connections, it also has to manage their entire lifecycle.

A Proposal to Simplify Things

One potential solution is to remove the responsibility of managing the vendor driver database connection lifecycle from JNoSQL database implementations.

Instead of acting as a factory for database connections, JNoSQL database implementations could accept pre-configured, externally managed connections. This would delegate connection lifecycle management to another component or process outside the JNoSQL framework.

What Are the Upsides and Downsides?

Pros:

• Developers gain full control over setting up and managing vendor driver connections, tailoring them to their specific needs.

• JNoSQL database implementations can focus solely on their core mission: facilitating seamless integration between Java applications and NoSQL databases.

Cons:

• Developers must take on the responsibility of managing the lifecycle of vendor driver connections. (this is something that it's already done by the way, isn't it?)

@otaviojava, do you have any thoughts or additional considerations to add to this discussion?

[otaviojava]

I agree that every vendor has different behavior, as you mentioned, but I believe that in this case, documentation or enhanced information will be better than not having it.

We could use, for example, the InputStream as a sample.

Where, the ByteArraInputStream explains that closing has not effect while with FileInputStream it does.

[dearrudam]

Absolutely! Improving the documentation is always a fantastic idea. Thanks for bringing it up, @otaviojava!

After giving it some thought, I believe it’s crucial to retain the existing vendor driver database connection factories in the implementation. These are essential for both developers who are already familiar with the framework and those just starting out.

That said, I think we can enhance this proposal further. Here’s what I suggest:

• Improve the documentation: Add more detailed information explaining how the database connection lifecycle is managed in each JNoSQL database implementation. Clear guidance can help developers better understand how connections work.

• Expand flexibility: Introduce a feature in JNoSQL database implementations to accept pre-configured vendor driver connections. This would give developers the option to set up and manage their connections as they see fit, catering to different use cases and preferences.

What do you think about this approach, everyone?

[rashtao]

Hi @dearrudam ,

thanks for clarifying this. I think it is a good idea to keep managing connections lifecycles inside JNOSQL, since this facilitates a lot the adoption of the framework.

IMHO, optionally accepting pre-configured vendor driver connections is also a interesting idea. This would allow the users to customize the connections to best fit their needs, i.e. setting connection options that are not configurable from JNOSQL database modules API.