[JBoss AS7 Development] - Format of a Detyped Operation Response
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"Format of a Detyped Operation Response"
To view the document, visit: http://community.jboss.org/docs/DOC-16354
--------------------------------------------------------------
+*Note: this document is a draft meant to spark discussion, and its content may undergo significant change*+
The basic method a user of the AS 7 programmatic managment API would use is very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of the return value.
For the format of the request, see this page (http://community.jboss.org/docs/DOC-16336).
h3. Simple Responses
Simple responses are provided by the following types of operations:
* Non-composite operations that target a single server. (See below for more on composite operations).
* Non-composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a simple read of a domain configuration property.)
The response will always include a simple boolean outcome field, with one of three possible values:
* success -- the operation executed successfully
* failed -- the operation failed
* cancelled -- the execution of the operation was cancelled. (This would be an unusual outcome for a simple operation which would generally very rapidly reach a point in its execution where it couldn't be cancelled.)
The other fields in the response will depend on whether the operation was sucessful.
The response for a failed operation:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message"
}
A response for a successful operation will include two fields:
* result -- the return value, or undefined for void operations or those that return null
* compensating-operation -- a complex structure in the format of an operation request (http://community.jboss.org/docs/DOC-16336) that the caller could use to reverse the affect of the operation. May be undefined if no compensating operation is available.
A non-void result with no compensating op available:
{
"outcome" => "success",
"result" => {
"name" => "Brian",
"age" => 22
},
"compensating-operation" => undefined
}
A void result with a compensating operation:
{
"outcome" => "success",
"result" => undefined,
"compensating-operation" => {
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
The response for a cancelled operation has no other fields:
{
"outcome" => "cancelled"
}
h3.
h3. Basic Composite Operation Responses
A composite operation is one that incorporates more than one simple operation in a list and executes them atomically. See the "Composite Operations" section http://community.jboss.org/docs/DOC-16336 here for more information.
Basic composite responses are provided by the following types of operations:
* Composite operations that target a single server.
* Composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a list of simple reads of domain configuration properties.)
The high level format of a basic composite operation response is largely the same as that of a simple operation response, although there is an important semantic difference. For a composite operation, the meaning of the outcome flag is controlled by the value of the operation request's rollback-on-runtime-failure field. If that field was false (default is true), the outcome flag will be success if *any* of the composite operation's steps was successful.
What's distinctive about a composite operation response is the result field. First, even if the operation was not successful, the result field will usually be present. (It won't be present if there was some sort of immediate failure that prevented the responder from even attempting to execute the individual operations.) Second, the content of the result field will be a list. Each element in the list will record the result of the corresponding element in the steps field of the composite operation request. So each individual operation in the composite operation will have its result recorded.
The individual operation results will have the same basic format as the simple operation results described above. However, there are some differences from the simple operation case when the individual operation's outcome flag is failed. These relate to the fact in a composite operation, individual operations can be rolled back or not even attempted.
If an individual operation was not even attempted (because the overall operation was cancelled or, more likely, a prior operation failed):
{
"outcome" => "cancelled"
}
An individual operation that failed and was rolled back:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => true
}
An individual operation that itself succeeded but was rolled back due to failure of another operation:
{
"outcome" => "failed",
"result" => {
"name" => "Brian",
"age" => 22
},
"rolled-back" => true
}
An operation where the attempt at rollback was unsuccessful:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => false,
"rollback-failure-description" => "[DOM-9876] Some other failure message"
}
Here's an example of the response for a successful 2 step composite operation:
{
"outcome" => "success",
"result" => [
{
"outcome" => "success",
"result" => {
"name" => "Brian",
"age" => 22
},
"compensating-operation" => undefined
},
{
"outcome" => "success",
"result" => undefined,
"compensating-operation" => {
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
],
"compensating-operation" => {
"operation" => "composite",
"address" => [],
"steps" => [{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}]
}
}
And for a failed 3 step composite operation, where the first step succeeded and the second failed, triggering cancellation of the 3rd and rollback of the others:
{
"outcome" => "failed",
"failure-description" => "[DOM-9999] Composite operation failed; see individual operation results for details",
"result" => [
{
"outcome" => "failed",
"result" => {
"name" => "Brian",
"age" => 22
},
"rolled-back" => true
},
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => true
},
{
"outcome" => "cancelled"
}
]
}
h3. Multi-Server Responses
Multi-server responses are provided by operations that target a DomainController or HostController and require the responder to apply the operation on multiple servers and aggregate their results (e.g. nearly all domain or host configuration updates.)
Multi-server operations are executed in several stages.
First, the operation may need to be applied against the authoritative configuration model maintained by the DomainController (for domain.xml confgurations) or a HostController (for a host.xml configuration). If there is a failure at this stage, the operation is automatically rolled back, with a response like this:
{
"outcome" => "failed",
"domain-failure-description" => "[DOM-3333] Failed to apply X to the domain model"
}
if the operation was addressed to the domain model, or like this:
{
"outcome" => "failed",
"host-failure-description" => "[DOM-3334] Failed to apply Y to the host model"
}
if the operation was addressed to a host model.
If the operation was addressed to the domain model, in the next stage the DomainController will ask each HostController to apply it to its local copy of the domain model. If any HostController fails to do so, the DomainController will tell all HostControllers to revert the change, and it will revert the change locally as well. The response to the client will look like this:
{
"outcome" => "failed",
"host-failure-descriptions" => {
"hostA" => "[DOM-3333] Failed to apply to the domain model",
"hostB" => "[DOM-3333] Failed to apply to the domain model"
}
}
If the preceding stages succeed, the operation will be pushed to all affected servers. If the operation is successful on all servers, the response will look like this (this operation has a void response, hence the result for each server is undefined):
{
"outcome" => "success",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
}
},
"compensating-operation" => {
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
The operation need not succeed on all servers in order to get an "outcome" => "success" result. All that is required is that it succeed on at least one server without the rollback policies in the rollout plan triggering a rollback on that server. (+TODO: consider something like "outcome" => "partial" for this case, and for partially successful composite operations.+) An example response in such a situation would look like this:
{
"outcome" => "success",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-3" => {
"host" => "host3",
"response" => {
"outcome" => "failed",
"failure-description" => "[DOM-4556] Something didn't work right",
"rolled-back" => true
}
}
}
},
"compensating-operation" => {
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
Finally, if the operation fails or is rolled back on all servers, an example response would look like this:
{
"outcome" => "failed",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "failed",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "failed",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-3" => {
"host" => "host3",
"response" => {
"outcome" => "failed",
"failure-description" => "[DOM-4556] Something didn't work right",
"rolled-back" => true
}
}
}
}
}
TODO: discuss some nuances related to multi-server composite operations, particularly the fact that different items in the composite may execute on different sets of servers, or only on the DC or the HC.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16354]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
[JBoss AS7 Development] - Format of a Detyped Operation Request
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"Format of a Detyped Operation Request"
To view the document, visit: http://community.jboss.org/docs/DOC-16336
--------------------------------------------------------------
The basic method a user of the AS 7 programmatic managment API would use it very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of operation.
h3. Simple Operations
A text representation of simple operation would look like this:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
}
Java code to produce that output would be:
ModelNode op = new ModelNode();
op.get("operation").set("setCoreThreads");
ModelNode addr = opB.get("address");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
System.out.println(op);
The order in which the items appear in the request is not relevant. The required elements are:
* operation -- String -- The name of the operation being invoked.
* address -- the address of the managed resource against which the request should be executed.
The other key/value pairs are parameter names and their values. The names and values should match what is specified in the operation's http://community.jboss.org/docs/DOC-16317 description.
Parameters may have any name, except for operation, address and rollout-plan.
h3. Composite Operations
The root resource managed by a (Domain|Host|Server)Controller will expose an operation named "composite". This operation executes a list of other operations as an atomic unit*. The structure of the request for the "composite" operations has the same fundamental structure as a simple operation (operation name, address, params as key value pairs.
+* See the discussion below of rollback-on-runtime-failure for how the atomicity requirement can be relaxed.+
{
"operation" => "composite",
"address" => [],
"steps" => [
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
},
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool2")
],
"count" => 5,
"per-cpu" => 10
}
],
"rollback-on-runtime-failure" => false
}
The "composite" operation takes two parameters:
* steps -- a list, where each item in the list has the same structure as a simple operation request. In the example above each of the two steps is modifying the thread pool configuration for a different pool. There need not be any particular relationship between the steps.
* rollback-on-runtime-failure -- boolean, optional, defaults to true. Whether steps that successfully execute should be reverted if other steps fail at runtime. Note that if any steps modify the persistent configuration, and any of those steps fail, all steps will be reverted. Partial/incomplete changes to the persistent configuration are not allowed. So, this flag only deals with what happens if there is a problem applying an operation to the running state of a server (e.g. actually increasing the size of a runtime thread pool.)
h3. Operations with a Rollout Plan
Operations targetted at domain or host level resources can potentially impact multiple servers. Such operations can include a "rollout plan" detailing the sequence in which the operation should be applied to servers as well as policies for detailing whether the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{
"operation" => "write-core-threads",
"address" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20,
"rollout-plan" => {
"in-series" => [
{
"concurrent-groups" => {
"groupA" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupB" => undefined
},
"server-group" => {"groupC" => {
"rolling-to-servers" => false,
"max-failed-servers" => 1
}}
},
{"server-group" => {"groupC" => undefined}},
{"concurrent-groups" => {
"groupD" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupE" => undefined
}}
]
},
"rollback-across-groups" => true
}
As you can see, the rollout plan is simply another structure at the same level as op, op-addr and the operation parameters. The root node of the structure allows two children:
* in-series -- a list -- A list of steps that are to be performed in series, with each step reaching completion before the next step is executed. Each step involves the application of the operation to the servers in one or more server groups. See below for details on each element in the list.
* rollback-across-groups -- boolean -- indicates whether the need to rollback the operation on all the servers in one server group should trigger a rollback across all the server groups. This is an optional setting, and defaults to false.
Each element in the list under the in-series node must have one or the other of the following structures:
* concurrent-groups -- a map of server group names to policies controlling how the operation should be applied to that server group. For each server group in the map, the operation may be applied concurrently. See below for details on the per-server-group policy configuration.
* server-group -- a single key/value mapping of a server group name to a policy controlling how the operation should be applied to that server group. See below for details on the policy configuration. +(Note: there is no difference in plan execution between this and a "concurrent-groups" map with a single entry.)+
The policy controlling how the operation is applied to the servers within a server group has the following elements, each of which is optional:
* rolling-to-servers -- boolean -- If true, the operation will be applied to each server in the group in series. If false or not specified, the operation will be applied to the servers in the group concurrently.
* max-failed-servers -- int -- Maximum number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
* max-failure-percentage -- int between 0 and 100 -- Maximum percentage of the total number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
If both max-failed-servers and max-failure-percentage are set to non-zero values, max-failure-percentage takes precedence.
Looking at the (contrived) example above, application of the operation to the servers in the domain would be done in 3 phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well. The 3 phases are:
1. Server groups groupA and groupB will have the operation applied concurrently. The operation will be applied to the servers in groupA in series, while all servers in groupB will handle the operation concurrently. If more than 20% of the servers in groupA fail to apply the operation, it will be rolled back across that group. If any servers in groupB fail to apply the operation it will be rolled back across that group.
2. Once all servers in groupA and groupB are complete, the operation will be applied to the servers in groupC. Those servers will handle the operation concurrently. If more than one server in groupC fails to apply the operation it will be rolled back across that group.
3. Once all servers in groupC are complete, server groups groupD and groupE will have the operation applied concurrently. The operation will be applied to the servers in groupD in series, while all servers in groupE will handle the operation concurrently. If more than 20% of the servers in groupD fail to apply the operation, it will be rolled back across that group. If any servers in groupE fail to apply the operation it will be rolled back across that group.
See also JBAS-8795 (https://issues.jboss.org/browse/JBAS-8795) for a suggestion on additional rollout plan capabilities.
h3. Default Rollout Plan
All operations that impact multiple servers will be executed with a rollout plan. However, actually specifying the rollout plan in the operation request is not required. If no rollout-plan is specified, a default plan will be generated. The plan will have the following characteristics:
* There will only be a single high level phase. All server groups affected by the operation will have the operation applied concurrently.
* Within each server group, the operation will be applied to all servers concurrently.
* Failure on any server in a server group will cause rollback across the group.
* Failure of any server group will result in rollback of all other server groups.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16336]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Emmanuel Bernard
Emmanuel Bernard [http://community.jboss.org/people/epbernard] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about the AS7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
4. Managed entities are detached at transaction end time.
2. No transaction invocation
1. Managed entities are detached at end of bean method call EntityManager call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. Managed entities continue to be managed at transaction commit time.
5. Managed entities are detached at transaction rollback time.
6. XPC is closed when dependent session bean(s) are closed (via @remove method).
7. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
4. If invoked without a JTA transaction and a transaction scoped persistence context is used, will throw TransactionRequiredException for any calls to entity manager remove/merge/persist/refresh.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
8. Fill in other deployment steps...
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. It should be easy to switch to a new persistence provider.
6. If an application bundles a persistence provider that is referenced from their persistence unit(s), use the bundled persistence provider (even if its a different version of a JPA 2.0 provider that is also available to all applications). This should handle bundling a different version of Hibernate.
7. Peace.
9. Questions1. The JPA specification section 7.9.1 (Container Responsibilities) implies that only one (container managed) entity manager will be associated with the JTA transaction. However, what if someone injects multiple persistence contexts (different persistent units) in separate entity managers for the same bean. Should that be considered an application error or allowed behaviour (e.g. each separate entity manager is joined to the JTA transaction). *ANSWER: we will allow it and design for it.*
2. For a few different cases, we will need to know which EntityManager was injected into a component. One such case is for XPC inheritance. For example, SFSB1 (with extended persistence context) gets injected into a web component and SFSB2 (with extended persistence context) gets injected into SFSB1. SFSB2 should inherit the XPC from SFSB1. Open question is how we want to maintain the bookkeeping for this. The JPA layer could expose a SPI like BeanToEntityManager{ List<EntityManager> getEntityManagers(); } that can be passed in on other SPI calls (basically depending on the EJB container to track injected EntityMangers via other magic). Another solution would be to track the mapping in the JPA layer (might be a pretty big map with a lot of weak references that need to be considerate of GC/undeploy concerns). Or perhaps there will some other solution that will appear for this. :)
3. What about injecting a Hibernate session or session factory as mentioned http://bill.burkecentral.com/2007/07/06/co-existence-with-hibernate-jpa-a... here. Do we want to carry this into AS7? Is there another way to do this that we would want to implement for AS7? [Emmanuel] I think this is valuable and quite natural. An alternative approach would be to let all injection logic be handle by Seam 3 which does Session/SessionFactory injection already (it also inject FullTextEntityManager and FullTextSession form Hibernate Search for that matter).
Illustration of how a stateful session bean (SFSB) named SFSB_XPC1 interacts with a stateless session bean (SLSB) named SLSB_PC2. Note that the extended persistence context (XPC) is injected into SFSB_XPC1 at bean creation time. Also note that the SFSB_XPC1 persistence context is bound to the JTA transaction and will be injected into the SLSB_PC2 by the EJB container as part of each invocation. The XPC1 will retain changes made by each invocation to SLSB_PC2 until the transaction commits.
|| *Action* || *Transaction* || *PersistenceContext
* ||
| SFSB_XPC1 created |
| XPC1 injected into SFSB_XPC1 |
| SFSB_XPC1.updateInventory | T1 started | XPC1 bound to T1 |
| SFSB_XPC1 calls SLSB_PC2 | T1 |
|
| SLSB_PC2.dowork | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity item1 | T1 | item1 is loaded |
| SLSB_PC2 persists new entity order1 | T1 | order1 will be saved at commit time |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 calls SLB_PC2 again | T1 |
|
| SLSB_PC2.morework | T1 | XPC1 injected into SLSB_PC2 EM instance |
| SLSB_PC2 loads entity order1 | T1 | order1 is returned from XPC1 |
| SLSB_PC2 calls order1.increase(4) | T1 | change made in XPC1 held entity |
| SLSB_PC2 returns | T1 |
|
| SFSB_XPC1 returns | T1 commit | XPC1 changes are saved, item1 + order1 remain in XPC1 |
| SFSB_XPC1 removed |
| XPC1 is closed |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
[EJB3 Development] - onetomany problem with null values in arraylist
by John Strandmyr
John Strandmyr [http://community.jboss.org/people/strandmyr] created the discussion
"onetomany problem with null values in arraylist"
To view the discussion, visit: http://community.jboss.org/message/581805#581805
--------------------------------------------------------------
Hi, this is my first post, so i hope im doing this right.
I have three entities that belong in a hiarchy. The entities are Prosess, ProsessTrinn and ProsessTrinnFare
defined in Prosess is:
@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
@JoinColumn (name="prosess_id")
public List<ProsessTrinn> prosessTrinn = new ArrayList<ProsessTrinn>();
This works fine.
In ProsessTrinn I have:
@OneToMany(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
@JoinColumn (name="prosesstrinn_id")
@IndexColumn(name="id")
public List<ProsessTrinnFare> farer = new ArrayList<ProsessTrinnFare>();
What happens is that all data is loaded, but a lot of null values are inserted in each of the arraylists. If i have 1 Prosess, 4 ProsessTrinn and each of those have 1 ProsessTrinnFare each, it results in 1, 2, 3 and 4 null values in the ArrayList. It may seem like the last entity to be loaded is inserted by index, and not reseting index for each of the Arraylists, causing there to be 1, 2, 3 and 4 null-values.
I know i can loop the arraylist on the getter, and remove null-values but seems like i've done something wrong and i'd rather correct that.
I'd apprechiate any hints and tips
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/581805#581805]
Start a new discussion in EJB3 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 3 months
[JBoss AS7 Development] - Format of a Detyped Operation Response
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"Format of a Detyped Operation Response"
To view the document, visit: http://community.jboss.org/docs/DOC-16354
--------------------------------------------------------------
+*Note: this document is a draft meant to spark discussion, and its content may undergo significant change*+
The basic method a user of the AS 7 programmatic managment API would use is very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of the return value.
For the format of the request, see this page (http://community.jboss.org/docs/DOC-16336).
h3. Simple Responses
Simple responses are provided by the following types of operations:
* Non-composite operations that target a single server. (See below for more on composite operations).
* Non-composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a simple read of a domain configuration property.)
The response will always include a simple boolean outcome field, with one of three possible values:
* success -- the operation executed successfully
* failed -- the operation failed
* cancelled -- the execution of the operation was cancelled. (This would be an unusual outcome for a simple operation which would generally very rapidly reach a point in its execution where it couldn't be cancelled.)
The other fields in the response will depend on whether the operation was sucessful.
The response for a failed operation:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message"
}
A response for a successful operation will include two fields:
* result -- the return value, or undefined for void operations or those that return null
* compensating-op -- a complex structure in the format of an operation request (http://community.jboss.org/docs/DOC-16336) that the caller could use to reverse the affect of the operation. May be undefined if no compensating operation is available.
A non-void result with no compensating op available:
{
"outcome" => "success",
"result" => {
"name" => "Brian",
"age" => 22
},
"compensating-op" => undefined
}
A void result with a compensating op:
{
"outcome" => "success",
"result" => undefined,
"compensating-op" => {
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
The response for a cancelled operation has no other fields:
{
"outcome" => "cancelled"
}
h3.
h3. Basic Composite Operation Responses
A composite operation is one that incorporates more than one simple operation in a list and executes them atomically. See the "Composite Operations" section http://community.jboss.org/docs/DOC-16336 here for more information.
Basic composite responses are provided by the following types of operations:
* Composite operations that target a single server.
* Composite operations that target a DomainController or HostController and don't require the responder to apply the operation on multiple servers and aggregate their results (e.g. a list of simple reads of domain configuration properties.)
The high level format of a basic composite operation response is largely the same as that of a simple operation response, although there is an important semantic difference. For a composite operation, the meaning of the outcome flag is controlled by the value of the operation request's rollback-on-runtime-failure field. If that field was false (default is true), the outcome flag will be success if *any* of the composite operation's steps was successful.
What's distinctive about a composite operation response is the result field. First, even if the operation was not successful, the result field will usually be present. (It won't be present if there was some sort of immediate failure that prevented the responder from even attempting to execute the individual operations.) Second, the content of the result field will be a list. Each element in the list will record the result of the corresponding element in the steps field of the composite operation request. So each individual operation in the composite operation will have its result recorded.
The individual operation results will have the same basic format as the simple operation results described above. However, there are some differences from the simple operation case when the individual operation's outcome flag is failed. These relate to the fact in a composite operation, individual operations can be rolled back or not even attempted.
If an individual operation was not even attempted (because the overall operation was cancelled or, more likely, a prior operation failed):
{
"outcome" => "cancelled"
}
An individual operation that failed and was rolled back:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => true
}
An individual operation that itself succeeded but was rolled back due to failure of another operation:
{
"outcome" => "failed",
"result" => {
"name" => "Brian",
"age" => 22
},
"rolled-back" => true
}
An operation where the attempt at rollback was unsuccessful:
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => false,
"rollback-failure-description" => "[DOM-9876] Some other failure message"
}
Here's an example of the response for a successful 2 step composite operation:
{
"outcome" => "success",
"result" => [
{
"outcome" => "success",
"result" => {
"name" => "Brian",
"age" => 22
},
"compensating-op" => undefined
},
{
"outcome" => "success",
"result" => undefined,
"compensating-op" => {
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
],
"compensating-op" => {
"op" => "composite",
"op-addr" => [],
"steps" => [{
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}]
}
}
And for a failed 3 step composite operation, where the first step succeeded and the second failed, triggering cancellation of the 3rd and rollback of the others:
{
"outcome" => "failed",
"failure-description" => "[DOM-9999] Composite operation failed; see individual operation results for details",
"result" => [
{
"outcome" => "failed",
"result" => {
"name" => "Brian",
"age" => 22
},
"rolled-back" => true
},
{
"outcome" => "failed",
"failure-description" => "[DOM-1234] Some failure message",
"rolled-back" => true
},
{
"outcome" => "cancelled"
}
]
}
h3. Multi-Server Responses
Multi-server responses are provided by operations that target a DomainController or HostController and require the responder to apply the operation on multiple servers and aggregate their results (e.g. nearly all domain or host configuration updates.)
Multi-server operations are executed in several stages.
First, the operation may need to be applied against the authoritative configuration model maintained by the DomainController (for domain.xml confgurations) or a HostController (for a host.xml configuration). If there is a failure at this stage, the operation is automatically rolled back, with a response like this:
{
"outcome" => "failed",
"domain-failure-description" => "[DOM-3333] Failed to apply X to the domain model"
}
if the operation was addressed to the domain model, or like this:
{
"outcome" => "failed",
"host-failure-description" => "[DOM-3334] Failed to apply Y to the host model"
}
if the operation was addressed to a host model.
If the operation was addressed to the domain model, in the next stage the DomainController will ask each HostController to apply it to its local copy of the domain model. If any HostController fails to do so, the DomainController will tell all HostControllers to revert the change, and it will revert the change locally as well. The response to the client will look like this:
{
"outcome" => "failed",
"host-failure-descriptions" => {
"hostA" => "[DOM-3333] Failed to apply to the domain model",
"hostB" => "[DOM-3333] Failed to apply to the domain model"
}
}
If the preceding stages succeed, the operation will be pushed to all affected servers. If the operation is successful on all servers, the response will look like this (this operation has a void response, hence the result for each server is undefined):
{
"outcome" => "success",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
}
},
"compensating-op" => {
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
The operation need not succeed on all servers in order to get an "outcome" => "success" result. All that is required is that it succeed on at least one server without the rollback policies in the rollout plan triggering a rollback on that server. (+TODO: consider something like "outcome" => "partial" for this case, and for partially successful composite operations.+) An example response in such a situation would look like this:
{
"outcome" => "success",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-3" => {
"host" => "host3",
"response" => {
"outcome" => "failed",
"failure-description" => "[DOM-4556] Something didn't work right",
"rolled-back" => true
}
}
}
},
"compensating-op" => {
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 5,
"per-cpu" => 5
}
}
Finally, if the operation fails or is rolled back on all servers, an example response would look like this:
{
"outcome" => "failed",
"server-groups" => {
"groupA" => {
"serverA-1" => {
"host" => "host1",
"response" => {
"outcome" => "success",
"result" => undefined
}
},
"serverA-2" => {
"host" => "host2",
"response" => {
"outcome" => "success",
"result" => undefined
}
}
},
"groupB" => {
"serverB-1" => {
"host" => "host1",
"response" => {
"outcome" => "failed",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-2" => {
"host" => "host2",
"response" => {
"outcome" => "failed",
"result" => undefined,
"rolled-back" => true
}
},
"serverB-3" => {
"host" => "host3",
"response" => {
"outcome" => "failed",
"failure-description" => "[DOM-4556] Something didn't work right",
"rolled-back" => true
}
}
}
}
}
TODO: discuss some nuances related to multi-server composite operations, particularly the fact that different items in the composite may execute on different sets of servers, or only on the DC or the HC.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16354]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months
[JBoss AS7 Development] - Format of a Detyped Operation Request
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] modified the document:
"Format of a Detyped Operation Request"
To view the document, visit: http://community.jboss.org/docs/DOC-16336
--------------------------------------------------------------
The basic method a user of the AS 7 programmatic managment API would use it very simple:
ModelNode execute(ModelNode operation) throws CancellationException, IOException;
where the return value is the detyped representation of the response, and operation is the detyped representation of the operating being invoked.
The purpose of this article is to document the structure of operation.
h3. Simple Operations
A text representation of simple operation would look like this:
{
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
}
Java code to produce that output would be:
ModelNode op = new ModelNode();
op.get("op").set("setCoreThreads");
ModelNode addr = opB.get("op-addr");
addr.add("base", "domain");
addr.add("profile", "production");
addr.add("subsystem", "threads");
addr.add("bounded-queue-thread-pool", "pool1");
op.get("count").set(0);
op.get("per-cpu").set(20);
System.out.println(op);
The order in which the items appear in the request is not relevant. The required elements are:
* op -- String -- The name of the operation being invoked.
* op-addr -- the address of the managed resource against which the request should be executed.
The other key/value pairs are parameter names and their values. The names and values should match what is specified in the operation's http://community.jboss.org/docs/DOC-16317 description.
Parameters may have any name, except for op, op-addr and rollout-plan.
h3. Composite Operations
The root resource managed by a (Domain|Host|Server)Controller will expose an operation named "composite". This operation executes a list of other operations as an atomic unit*. The structure of the request for the "composite" operations has the same fundamental structure as a simple operation (operation name, address, params as key value pairs.
+* See the discussion below of rollback-on-runtime-failure for how the atomicity requirement can be relaxed.+
{
"op" => "composite",
"op-addr" => [],
"steps" => [
{
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20
},
{
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool2")
],
"count" => 5,
"per-cpu" => 10
}
],
"rollback-on-runtime-failure" => false
}
The "composite" operation takes two parameters:
* steps -- a list, where each item in the list has the same structure as a simple operation request. In the example above each of the two steps is modifying the thread pool configuration for a different pool. There need not be any particular relationship between the steps.
* rollback-on-runtime-failure -- boolean, optional, defaults to true. Whether steps that successfully execute should be reverted if other steps fail at runtime. Note that if any steps modify the persistent configuration, and any of those steps fail, all steps will be reverted. Partial/incomplete changes to the persistent configuration are not allowed. So, this flag only deals with what happens if there is a problem applying an operation to the running state of a server (e.g. actually increasing the size of a runtime thread pool.)
h3. Operations with a Rollout Plan
Operations targetted at domain or host level resources can potentially impact multiple servers. Such operations can include a "rollout plan" detailing the sequence in which the operation should be applied to servers as well as policies for detailing whether the operation should be reverted if it fails to execute successfully on some servers.
If the operation includes a rollout plan, the structure is as follows:
{
"op" => "write-core-threads",
"op-addr" => [
("profile" => "production"),
("subsystem" => "threads"),
("bounded-queue-thread-pool" => "pool1")
],
"count" => 0,
"per-cpu" => 20,
"rollout-plan" => {
"in-series" => [
{
"concurrent-groups" => {
"groupA" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupB" => undefined
},
"server-group" => {"groupC" => {
"rolling-to-servers" => false,
"max-failed-servers" => 1
}}
},
{"server-group" => {"groupC" => undefined}},
{"concurrent-groups" => {
"groupD" => {
"rolling-to-servers" => true,
"max-failure-percentage" => 20
},
"groupE" => undefined
}}
]
},
"rollback-across-groups" => true
}
As you can see, the rollout plan is simply another structure at the same level as op, op-addr and the operation parameters. The root node of the structure allows two children:
* in-series -- a list -- A list of steps that are to be performed in series, with each step reaching completion before the next step is executed. Each step involves the application of the operation to the servers in one or more server groups. See below for details on each element in the list.
* rollback-across-groups -- boolean -- indicates whether the need to rollback the operation on all the servers in one server group should trigger a rollback across all the server groups. This is an optional setting, and defaults to false.
Each element in the list under the in-series node must have one or the other of the following structures:
* concurrent-groups -- a map of server group names to policies controlling how the operation should be applied to that server group. For each server group in the map, the operation may be applied concurrently. See below for details on the per-server-group policy configuration.
* server-group -- a single key/value mapping of a server group name to a policy controlling how the operation should be applied to that server group. See below for details on the policy configuration. +(Note: there is no difference in plan execution between this and a "concurrent-groups" map with a single entry.)+
The policy controlling how the operation is applied to the servers within a server group has the following elements, each of which is optional:
* rolling-to-servers -- boolean -- If true, the operation will be applied to each server in the group in series. If false or not specified, the operation will be applied to the servers in the group concurrently.
* max-failed-servers -- int -- Maximum number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
* max-failure-percentage -- int between 0 and 100 -- Maximum percentage of the total number of servers in the group that can fail to apply the operation before it should be reverted on all servers in the group. The default value if not specified is zero; i.e. failure on any server triggers rollback across the group.
If both max-failed-servers and max-failure-percentage are set to non-zero values, max-failure-percentage takes precedence.
Looking at the (contrived) example above, application of the operation to the servers in the domain would be done in 3 phases. If the policy for any server group triggers a rollback of the operation across the server group, all other server groups will be rolled back as well. The 3 phases are:
1. Server groups groupA and groupB will have the operation applied concurrently. The operation will be applied to the servers in groupA in series, while all servers in groupB will handle the operation concurrently. If more than 20% of the servers in groupA fail to apply the operation, it will be rolled back across that group. If any servers in groupB fail to apply the operation it will be rolled back across that group.
2. Once all servers in groupA and groupB are complete, the operation will be applied to the servers in groupC. Those servers will handle the operation concurrently. If more than one server in groupC fails to apply the operation it will be rolled back across that group.
3. Once all servers in groupC are complete, server groups groupD and groupE will have the operation applied concurrently. The operation will be applied to the servers in groupD in series, while all servers in groupE will handle the operation concurrently. If more than 20% of the servers in groupD fail to apply the operation, it will be rolled back across that group. If any servers in groupE fail to apply the operation it will be rolled back across that group.
See also JBAS-8795 (https://issues.jboss.org/browse/JBAS-8795) for a suggestion on additional rollout plan capabilities.
h3. Default Rollout Plan
All operations that impact multiple servers will be executed with a rollout plan. However, actually specifying the rollout plan in the operation request is not required. If no rollout-plan is specified, a default plan will be generated. The plan will have the following characteristics:
* There will only be a single high level phase. All server groups affected by the operation will have the operation applied concurrently.
* Within each server group, the operation will be applied to all servers concurrently.
* Failure on any server in a server group will cause rollback across the group.
* Failure of any server group will result in rollback of all other server groups.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16336]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 3 months