[JBoss JIRA] (TEIIDSB-109) Allow for the usage of the spring platform transaction manager in more scenarios
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-109?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-109:
---------------------------------
Fix Version/s: (was: 1.4.0)
> Allow for the usage of the spring platform transaction manager in more scenarios
> --------------------------------------------------------------------------------
>
> Key: TEIIDSB-109
> URL: https://issues.redhat.com/browse/TEIIDSB-109
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: core
> Reporter: Steven Hawkins
> Priority: Major
>
> Unless an xa source is being used, we would ideally use the default platform transaction manager. This would map updates over multiple sources to best effort single phase commit. This will likely be the majority of our usage.
> The problem is that the platform transaction manager doesn't directly support a suspend/resume concept that is needed for our remote pg/jdbc processing logic that allows the processing thread to detach from the current work when blocked and do something else.
> It would be worth investigating if this functionality could be added to spring boot or if there is is some other approach that was missed with the initial investigation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIIDSB-163) Provide pooling for BaseConnectionFactory sources
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-163?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-163:
---------------------------------
Fix Version/s: 1.5.0
(was: 1.4.0)
> Provide pooling for BaseConnectionFactory sources
> -------------------------------------------------
>
> Key: TEIIDSB-163
> URL: https://issues.redhat.com/browse/TEIIDSB-163
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: datasource
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.5.0
>
>
> It will depend on the source and the cost of creating a connection, but in general we should provide pooling for connections rather than creating the for every operation. For example salesforce is a heavy weight connection.
> The pooling will need to be tied into spring security or jca like logic to properly manage connections by identity once we re-establish that logic.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (TEIIDSB-157) Support loading password credential from infinispan secret
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-157?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-157:
---------------------------------
Fix Version/s: 1.5.0
(was: 1.4.0)
> Support loading password credential from infinispan secret
> ----------------------------------------------------------
>
> Key: TEIIDSB-157
> URL: https://issues.redhat.com/browse/TEIIDSB-157
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: datasource
> Reporter: Steven Hawkins
> Priority: Major
> Fix For: 1.5.0
>
> Original Estimate: 5 hours
> Time Spent: 2 hours
> Remaining Estimate: 3 hours
>
> The infinispan operator generates a secret that contains a yaml file, which is where the developer password is stored.
> There three approaches:
> 1. for materialization assume that we will "own" the DataGrid instance such that we'll create and pass our own secret file for infinispan to use. In this case we'll know the password and can provide that to the connection factory via an env property.
> 2. add logic to the connection factory to specify a "credential file" such that we'll parse the yaml from the given location (a mount of the secret) and find the appropriate credential for the given username (typically developer).
> 3. ask the infinispan team to allow for easier consumption of the secret (a secret per user?)
> To get things working with the example, I can take the first approach - but it will look a little convoluted.
> In general 2 or 3 will be needed in scenarios where we expect to simply pick up existing credentials.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months