search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.16k stars 598 forks source link

Provide prepopulation and maintenance of the JDBC connection pool #14900

Open frowe opened 4 years ago

frowe commented 4 years ago

Description

As a server administrator, I want to be able to configure a number of connections to a database that will be created and maintained by the server, so I can ensure that applications will not have to wait for connection creation, allowing them to meet specific service level agreements (SLA) for response times.

For this use case, we need to provide the ability to configure a number of connections to be created at JDBC service startup and the ability to maintain these connections to avoid network timeouts and/or inactivity closure. Creation of the initial connections will need to be spaced such that it doesn't overwhelm the connected resource. Whether and how the connections are maintained by the server should be configurable.

Documents

When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.

General Instructions

The process steps occur roughly in the order as presented. Process steps occasionally overlap.

Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").

Unless otherwise indicated, the tasks are the responsibility of the Feature Owner or a Delegate of the Feature Owner.

If you need assistance, reach out to the OpenLiberty/release-architect.

Important: Labels are used to trigger particular steps and must be added as indicated.

Prioritization (Complete Before Development Starts)

The (OpenLiberty/chief-architect) and area leads are responsible for prioritizing the features and determining which features are being actively worked on.

Prioritization

Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID.

Design Preliminaries

Design

No Design

FAT Documentation

A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it kind=noship or beta fencing it.
Code may not GA until this feature has obtained the "Design Approved" or "No Design Approved" label, along with all other tasks outlined in the GA section.

Feature Development Begins

Legal and Translation

In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. Both MUST be completed before Beta or GA is requested.

Legal (Complete before Feature Complete Date)

Translation (Complete 1 week before Feature Complete Date)

Innovation (Complete 1 week before Feature Complete Date)

In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.

Beta Code

Beta Blog (Complete 1.5 weeks before beta eGA)

A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.

Feature Complete

Focal Point Approvals (Complete by Feature Complete Date)

These occur only after GA of this feature is requested (by adding a target:ga label). GA of this feature may not occur until all approvals are obtained.

All Features

Design Approved Features

Remove Beta Fencing (Complete by Feature Complete Date)

GA Blog (Complete by Feature Complete Date)

Post GA

frowe commented 3 years ago

UFO socialization issues: Note, as discussed on several slides, the exact syntax for the minPoolSizeMaintainedAt attribute will be determined in a separate Design Issues meeting. Once agreed up, the UFO will be updated with that info. Slide 33 bullet 3 - it was noticed that feature should use Liberty standard convention for handling config problems, the onError attribute (fail/warn/ignore)

NottyCode commented 3 years ago

As discussed off GitHub I think we should drop the auth alias for maintaining the connection pool minimum and instead just rely on the container auth alias.

samwatibm commented 3 years ago

RFE's have moved:

Can't find the equivalent for http://www.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=70807 because it's now closed

frowe commented 3 years ago

@samwatibm

Can't find the equivalent for http://www.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=70807 because it's now closed Not sure what you mean by "Can't find equivalent..."

samwatibm commented 3 years ago

@frowe External RFEs in DeveloperWorks has migrated to Aha and will eventually go away. (See the warning on top of your 1st RFE, 144070.)

70807 is closed so it was never migrated to Aha. If the info there is important, please capture it somewhere.

frowe commented 1 year ago

@malincoln Per your request for status, this issue is not currently in progress, but as we're wrapping up jakarta ee10 work, we'll restart work on it.