[JBoss JIRA] (WFLY-7207) Integration with transactions during the graceful shutdown
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/WFLY-7207?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris commented on WFLY-7207:
---------------------------------------
Relevant transactions JIRA issue hasn't reached the design phase, so there is no possible SPI interface. However, because of the issue being critical and time for release running shorter, I'm raising this issue now in case you need to do any analysis in your part.
> Integration with transactions during the graceful shutdown
> ----------------------------------------------------------
>
> Key: WFLY-7207
> URL: https://issues.jboss.org/browse/WFLY-7207
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Gytis Trikleris
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7207) Integration with transactions during the graceful shutdown
by Gytis Trikleris (JIRA)
Gytis Trikleris created WFLY-7207:
-------------------------------------
Summary: Integration with transactions during the graceful shutdown
Key: WFLY-7207
URL: https://issues.jboss.org/browse/WFLY-7207
Project: WildFly
Issue Type: Feature Request
Components: EJB
Reporter: Gytis Trikleris
Priority: Critical
Fix For: 11.0.0.Alpha1
During the graceful shutdown EJB subsystem should consult Transactions subsystem whether the requests should be rejected or not. Transaction subsystem would check for availability of JTA or JTS transaction and return the outcome.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7206) Graceful Shutdown and Quiescing for Transactions
by Gytis Trikleris (JIRA)
Gytis Trikleris created WFLY-7206:
-------------------------------------
Summary: Graceful Shutdown and Quiescing for Transactions
Key: WFLY-7206
URL: https://issues.jboss.org/browse/WFLY-7206
Project: WildFly
Issue Type: Feature Request
Components: Server, Transactions, Web Console, XTS
Reporter: Gytis Trikleris
Assignee: Gytis Trikleris
Priority: Critical
Fix For: 11.0.0.Alpha1
* During the quiesce period - the server component will not accept new requests.
* Components of the server will support controlled shutdown or quiescence - ie. In-flight transactions and requests will be serviced before the shutdown.
This also implies eing able to control all request paths - HTTP (via mod_cluster), JMS and RMI (via smart proxies).
* The Quiesce operation will accept a timeout which will indicate the maximum period that a shutdown will wait for in-flight requests / transactions to complete. After the timeout expires the server component will shutdown immediately.
* It applies to servers that are started with all supported server profiles (i.e. default, default-ha, full and full-ha) in both standalone and domain modes.
* In a clustered environment if a node in cluster is on graceful shutdown, the other node(s) in the cluster should not log warnings, but infos (or debug or nothing) because this is a normal situation (Ref: PRODMGT-815)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7205) Enhance coverage of transaction timeout test cases
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created WFLY-7205:
-------------------------------------
Summary: Enhance coverage of transaction timeout test cases
Key: WFLY-7205
URL: https://issues.jboss.org/browse/WFLY-7205
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Affects Versions: 10.1.0.Final
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
Priority: Minor
There is not much tests which checks behaviour of CMT/BMT EJBs when transaction timeout occurs.
There should be more such tests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7130) PersistenceProperty specified in @PersistenceContext should be passed to the created EntityManager
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7130?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-7130.
------------------------------
> PersistenceProperty specified in @PersistenceContext should be passed to the created EntityManager
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-7130
> URL: https://issues.jboss.org/browse/WFLY-7130
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.1.1.Final, 10.1.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
>
> While working on the unit test for WFLY-7075, I noticed that PersistenceContext properties are not being passed correctly to the Injected EntityManager, we should fix that.
> For Example:
> {quote}
> @PersistenceContext(type = PersistenceContextType.TRANSACTION, unitName = "mypc", properties={@PersistenceProperty(name="wildfly.jpa.allowjoinedunsync", value="true")})
> private EntityManager allowjoinedunsyncEm;
> {quote}
> Is passing an incorrect form of the property values.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-7075.
------------------------------
> proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
> Attachments: kitchensink-ear.rar, Screenshot_10.png, Screenshot_7.png, Screenshot_8.png, Screenshot_9.png
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> [WFLY-7108] is now the tracking jira for the fix.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months