[JBoss JIRA] (WFCORE-1201) Could not upload new deployment
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-1201:
---------------------------------
Fix Version/s: 2.0.11.Final
(was: 2.0.8.Final)
> Could not upload new deployment
> -------------------------------
>
> Key: WFCORE-1201
> URL: https://issues.jboss.org/browse/WFCORE-1201
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: 2 different machines
> Linux Debian Squeeze & Jessie
> Oracle Java SE 8
> Reporter: Claudio Weiler
> Assignee: Harald Pehl
> Fix For: 2.0.11.Final
>
>
> WildFly stop to accept deployments via interface upload with following stacktrace:
> ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data
> at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203)
> at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Same artifact was used before with success, nothing changed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned WFLY-1033:
-----------------------------------
Assignee: Gytis Trikleris
> Enhance XTS AS7 configuration
> -----------------------------
>
> Key: WFLY-1033
> URL: https://issues.jboss.org/browse/WFLY-1033
> Project: WildFly
> Issue Type: Enhancement
> Components: XTS
> Reporter: Andrew Dinn
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-1033) Enhance XTS AS7 configuration
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-1033?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-1033:
--------------------------------
Fix Version/s: 11.0.0.Alpha1
> Enhance XTS AS7 configuration
> -----------------------------
>
> Key: WFLY-1033
> URL: https://issues.jboss.org/browse/WFLY-1033
> Project: WildFly
> Issue Type: Enhancement
> Components: XTS
> Reporter: Andrew Dinn
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The current integration of XTS into AS7 as an AS7 extension allows optional configuration of the coordinator URL from the <xts/> element in the AS7 standalone configuration file. No other configuration options are currently supported.
> XTS ought to support more precise configuration. IN particular, it ought to be possible to enable or disable deployment of coordinator, participant or client services independently and also to choose whether to deploy WS-AT or WS-BA services or both. This requires selectively deploying only the required web service endpoints, selectively executing the required initialization routines and selectively loading the required high level service implementations and context factory implementations.
> The XTS implementation has already been factored so as to to support such discriminated bootstrapping. So this task only requires modifying the AS7 extension code to manage the relevant configuration information and install the relevant values into the XTS environment configuration beans before starting the XTS service.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2387:
------------------------------------
I pushed a (work in progress) hack to [https://github.com/scottmarlow/wildfly/tree/orm51] that passes the org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase test case that Tomas Remes provided. This is with the [https://hibernate.atlassian.net/browse/HHH-8706] changes that Steve Ebersole push to the Hibernate master branch.
I also tried the [https://hibernate.atlassian.net/browse/HHH-10477] change on the ORM 5.0 branch, with the EntityListenerInjectionSupportTestCase test changed to set persistence unit property "hibernate.delay_cdi_access=true" and that also passed.
Additional status updates are in comments on HHH-8706.
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable
by Stephen Fikes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ]
Stephen Fikes updated WFLY-6096:
--------------------------------
Component/s: Clustering
(was: ConfigAdmin)
> ISPN-5876 changes need to be configurable
> -----------------------------------------
>
> Key: WFLY-6096
> URL: https://issues.jboss.org/browse/WFLY-6096
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Reporter: Stephen Fikes
> Assignee: Thomas Diesler
>
> When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
> For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
> As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
> Though the second case _may_ be the more common, it seems like the default should be to not reduce the integrity guarantee.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5520) Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5520:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/8610 (was: https://github.com/wildfly/wildfly/pull/8481)
> Manually migrated EAP 6.x profiles fail to boot due to 'default-clustered-sfsb-cache' used in runtime
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 10.0.0.Final
>
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable
by Stephen Fikes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ]
Stephen Fikes updated WFLY-6096:
--------------------------------
Description:
When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
Though the second case _may_ be the more common, it seems like the default should be to not reduce the integrity guarantee.
was:
When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
> ISPN-5876 changes need to be configurable
> -----------------------------------------
>
> Key: WFLY-6096
> URL: https://issues.jboss.org/browse/WFLY-6096
> Project: WildFly
> Issue Type: Feature Request
> Components: ConfigAdmin
> Reporter: Stephen Fikes
> Assignee: Thomas Diesler
>
> When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
> For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
> As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
> Though the second case _may_ be the more common, it seems like the default should be to not reduce the integrity guarantee.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable
by Stephen Fikes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ]
Stephen Fikes updated WFLY-6096:
--------------------------------
Description:
When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
was:
When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in https://issues.jboss.org/browse/ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
> ISPN-5876 changes need to be configurable
> -----------------------------------------
>
> Key: WFLY-6096
> URL: https://issues.jboss.org/browse/WFLY-6096
> Project: WildFly
> Issue Type: Feature Request
> Components: ConfigAdmin
> Reporter: Stephen Fikes
> Assignee: Thomas Diesler
>
> When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
> For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
> As discussed in ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable
by Stephen Fikes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ]
Stephen Fikes updated WFLY-6096:
--------------------------------
Description:
When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of https://issues.jboss.org/browse/ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in https://issues.jboss.org/browse/ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
was:
When Infinispan 8.1 is incorporated in WildFly, the changes added as part of https://issues.jboss.org/browse/ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in https://issues.jboss.org/browse/ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
> ISPN-5876 changes need to be configurable
> -----------------------------------------
>
> Key: WFLY-6096
> URL: https://issues.jboss.org/browse/WFLY-6096
> Project: WildFly
> Issue Type: Feature Request
> Components: ConfigAdmin
> Reporter: Stephen Fikes
> Assignee: Thomas Diesler
>
> When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of https://issues.jboss.org/browse/ISPN-5876 should be made non-default.
> For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
> As discussed in https://issues.jboss.org/browse/ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6096) ISPN-5876 changes need to be configurable
by Stephen Fikes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6096?page=com.atlassian.jira.plugin.... ]
Stephen Fikes updated WFLY-6096:
--------------------------------
Description:
When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in https://issues.jboss.org/browse/ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
was:
When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of https://issues.jboss.org/browse/ISPN-5876 should be made non-default.
For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
As discussed in https://issues.jboss.org/browse/ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
> ISPN-5876 changes need to be configurable
> -----------------------------------------
>
> Key: WFLY-6096
> URL: https://issues.jboss.org/browse/WFLY-6096
> Project: WildFly
> Issue Type: Feature Request
> Components: ConfigAdmin
> Reporter: Stephen Fikes
> Assignee: Thomas Diesler
>
> When Infinispan 8.1 is incorporated in WildFly (WFLY-6094), the changes added as part of ISPN-5876 should be made non-default.
> For the databases that default to read blocking on modified rows (e.g. SQLServer) and for applications which can be designed to support pessimistic locking for all reads, the changes reduce the level of data integrity that can be guaranteed.
> As discussed in https://issues.jboss.org/browse/ISPN-5876, for databases which do not default to read blocking on modified rows or applications which cannot tolerate the cost of pessimistic locking, the changes address the case where stale data may be loaded and retained until explicitly evicted or timed out.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months