[JBoss JIRA] (WFLY-8483) Upgrade IronJacamar to 1.4.3 from 1.4.2
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-8483?page=com.atlassian.jira.plugin.... ]
Stefano Maestri moved JBEAP-10059 to WFLY-8483:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8483 (was: JBEAP-10059)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Fix Version/s: (was: 7.1.0.DR12)
> Upgrade IronJacamar to 1.4.3 from 1.4.2
> ---------------------------------------
>
> Key: WFLY-8483
> URL: https://issues.jboss.org/browse/WFLY-8483
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> This is needed to adjust the SPI needed for the Elytron integration for the three JCA subsystems
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
Tomas Hofman commented on JBJCA-1338:
-------------------------------------
New PR with solution #2 from previous post: https://github.com/ironjacamar/ironjacamar/pull/623
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
Tomas Hofman commented on JBJCA-1338:
-------------------------------------
Commit was rolled back due to this regression: https://issues.jboss.org/browse/JBEAP-9730
Some analysis:
# The change I'd made set {{autocommit = true}} on the jdbc connection and reset the {{underlyingAutoCommit}} var in the {{BaseWrapperManagedConnection#cleanup()}} method:
{code}
BaseWrapperManagedConnection#cleanup():
jdbcAutoCommit = true;
+ if (jdbcAutoCommit != underlyingAutoCommit)
+ {
+ try {
+ con.setAutoCommit(jdbcAutoCommit);
+ underlyingAutoCommit = jdbcAutoCommit;
+ } catch (SQLException e) {
+ mcf.log.errorResettingAutoCommit(mcf.getJndiName(), e);
+ }
+ }
{code}
# That broke following fix in the {{destroy()}} method, which depended on {{underlyingAutoCommit}} var:
{code}
BaseWrapperManagedConnection#destroy():
// See JBAS-5678
if (!underlyingAutoCommit)
con.rollback();
{code}
so the connection was not rolled back on destroy caused by a connection error and the transaction somehow got committed.
*But* that actually wasn't the reason why the test failed, as this fix is probably only relevant to Oracle db, which apparently commits a transaction when closing the connection (JBAS-5678).
# The reason of the test failure is that postgresql driver commits a running transaction when autocommit is set to true:
{code}
PgConnection:
public void setAutoCommit(boolean autoCommit) throws SQLException {
checkClosed();
if (this.autoCommit == autoCommit) {
return;
}
if (!this.autoCommit) {
commit();
}
this.autoCommit = autoCommit;
}
{code}
# Also related - normally if a transaction is left open and a managed connection is closed, the transaction is closed in {{TxConnectionListener.tidyup()}}. That doesn't happen if the connection is closed due to connection error:
{code}
AbstractConnectionManager#returnManagedConnection():
if (!kill && cl.getState().equals(ConnectionState.NORMAL))
{
cl.tidyup();
}
{code}
Possible solutions:
# Continue with the old fix, just add {{con.rollback()}} before {{con.setAutoCommit(true)}} in the {{cleanup()}} method.
# Rather then in the cleanup method, we could reset autocommit state in {{BaseWrapperManagedConnectionFactory#getInvalidConnections()}} just before validating the connection, where there should be no running transaction present...
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1145:
-------------------------------
Fix Version/s: 3.0.0.Beta13
(was: 3.0.0.Beta12)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron, domain-mode
> Fix For: 3.0.0.Beta13
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-887:
------------------------------
Fix Version/s: 3.0.0.Beta13
(was: 3.0.0.Beta12)
> "Deprecate" using an expression in model refs to interfaces
> -----------------------------------------------------------
>
> Key: WFCORE-887
> URL: https://issues.jboss.org/browse/WFCORE-887
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Beta13
>
>
> SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions.
> Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1.
> There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support.
> We should look for other cases like this too, although those changes should be separate JIRAs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFCORE-396:
------------------------------
Fix Version/s: 3.0.0.Beta13
(was: 3.0.0.Beta12)
> Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-396
> URL: https://issues.jboss.org/browse/WFCORE-396
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta13
>
>
> Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.)
> But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years