[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-162: ----------------------------------- @PersistenceContext and @PersistenceUnit are aways bound to the component (per the EJB spec). You can bind the EntityManager to a scope with a simple producer method. Currently @RequestScoped is the only thing which makes sense atm imo (as the EM is not Serializable as per the JPA spec) See CDI-121 for @TransactionScoped which would also be handy in the future. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Scott Marlow commented on CDI-162: ---------------------------------- What would the obstacles be from a CDI point of view? I think that handling extended persistence context inheritance across different component types would be possible (in theory). Since clustering an extended persistence context, isn't defined by any specifications, it probably isn't a blocking requirement to figure out how that would be done. However, serializing/deserializing the component chain when a managed bean is the top level component, would be good to consider (with regard to how that could work for implementations that support clustering of extended persistence contexts). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-162: ------------------------------- I think it would need to be bound to a scope, not to a component. I don't particularly see any obstacles from a CDI perspective. As Mark points out, trying to serialize the EntityManager isn't possible, so defining this for non-passivating scopes only is really our only option, in a clustered environment (or any other environment which tries to serialize the session). Scott, can you elaborate on what you mean about "serializing/deserializing the component chain when a managed bean is the top level component" - what do you need concretely? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Scott Marlow commented on CDI-162: ---------------------------------- The extended persistence context (EntityManager) could be serializable. If the extended persistence context is not serializable the stateful bean will not be serializable as well. I'm not sure if this helps [with the concern raised here|https://struberg.wordpress.com/2012/04/25/is-there-a-way-to-fix-the-...]. {quote} 4.2 Conversational State of a Stateful Session Bean The conversational state of a stateful session object is defined as the session bean instance’s field values, its associated interceptors and their instance field values, plus the transitive closure of the objects from these instances’ fields reached by following Java object references. To efficiently manage the size of its working set, a session bean container may need to temporarily transfer the state of an idle stateful session bean instance to some form of secondary storage. The transfer from the working set to secondary storage is called instance passivation. The transfer back is called activation. In advanced cases, a session object’s conversational state may contain open resources, such as open sockets and open database cursors. A container cannot retain such open resources when a session bean instance is passivated. A developer of a stateful session bean must close and open the resources in the A container may only passivate a stateful session bean instance when the instance is not in a transaction. A container must not passivate a stateful session bean with an extended persistence context unless the following conditions are met:[9] * All the entities in the persistence context are serializable. * The EntityManager is serializable. A stateless session bean is never passivated. [8] PrePassivate and PostActivate lifecycle callback interceptor methods. [9] The container is not permitted to destroy a stateful session bean instance because it does not meet these requirements. {quote} What I mean concretely about the top level component, is as follows. The extended persistence context is created at the time that a stateful bean is created (injection or jndi lookup) and that stateful bean is the "top most" stateful bean. When the "top most" stateful bean, injects or lookups another stateful bean that also has the same named extended persistence context, the additional bean inherits the extended persistence context. For the concrete example, please consider two cases, where the managed bean is the top most bean that has looked up a stateful session bean. I'm not quite sure what it would mean for the stateful session bean instance to be passivated (since the top most managed bean will still reference the persistence context (keeping the xpc pinned in memory). Even worse, would be if we are clustering and we failover the stateful session bean to another cluster node. I think for both of these respective cases, the managed bean would need to also be passivated or failed over to the same cluster node as the stateful bean. Does this make any sense? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-162: ------------------------------- Actually, the EntityManager bean that is produced by Arne's code sample is passivation capable. As defined by 3.6.1, the bean is a "resource bean". And from 6.6.2 "all resources are passivation capable dependencies". So the CDI container will not choke on this definition. However, the real problem is the one Arne outlines in the last paragraph. Scott, the clustering team @ JBoss always planned to do some work on this. Do you know the status? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Scott Marlow commented on CDI-162: ---------------------------------- AS7-4940 isn't directly related, but impacts whether the extended persistence context inheritance will be simple single level (shallow) or multiple level (deep). The [JPA 2.1 eg had some discussion but tabled it|http://java.net/nonav/projects/jpa-spec/lists/users/archive/2012-06/me...], until there is more interest from developers expressed. Currently, AS7-4940 is only about a JBoss AS extension. I don't think it directly impacts this effort but something to note for future reference back to this discussion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Scott Marlow edited comment on CDI-162 at 9/18/12 9:39 AM: ----------------------------------------------------------- [~pmuir] AS7-4940 isn't directly related, but impacts whether the extended persistence context inheritance will be simple single level (shallow) or multiple level (deep). The [JPA 2.1 eg had some discussion but tabled it|http://java.net/nonav/projects/jpa-spec/lists/users/archive/2012-06/me...], until there is more interest from developers expressed. Currently, AS7-4940 is only about a JBoss AS extension. I don't think it directly impacts this effort but something to note for future reference back to this discussion. was (Author: smarlow): AS7-4940 isn't directly related, but impacts whether the extended persistence context inheritance will be simple single level (shallow) or multiple level (deep). The [JPA 2.1 eg had some discussion but tabled it|http://java.net/nonav/projects/jpa-spec/lists/users/archive/2012-06/me...], until there is more interest from developers expressed. Currently, AS7-4940 is only about a JBoss AS extension. I don't think it directly impacts this effort but something to note for future reference back to this discussion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-162: ----------------------------------- [~smarlow] The problem is that the JPA spec not only allows optimistic locking but also pessimistic locking. I have not found any restriction while reading through the EJB spec, so I assume this is still true for Entities managed via UserTransactions, isn't? We agree that pessimistic locking ("SELECT ... FOR UPDATE") always creates a database lock and thus such JPA entities cannot get moved to another node, right? There is just no way around it! But even with optimistic locking in place (which requires some kind of versioning on each table) you can only move the entity to another node if you also transmit the version information. But sadly JPA doesn't require to mandatory add a @Version field to an entity. You will btw again have the same problem if you use EJBs + DTOs and do not store the version information in the DTO (and manually check it if you like to save back the information). (I guess I'm save to assume that it's clear how optimistic locking works, right?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-162: ----------------------------------- [~arnemlim] True, but if you look at classic 3270 apps, then the 'transaction' starts if a user opens a screen for editing and it only ends after the user exits the screen. In the optimistic locking scenarios which are almost exclusively used for web applications you have 2 kind of transactions. The technical db transaction and a 'logical transaction' which is accomplished by the optimistic lock. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Scott Marlow commented on CDI-162: ---------------------------------- [~struberg] Perhaps I have some preconceived notion about how clustering should work, that is blinding me to the underlying issue. I admit to thinking about clustering in JBoss AS terms because that is what I am most familiar with (cluster replication will not occur in the middle of a JTA transaction in JBoss AS). EE also doesn't define how clustering should work but for the purposes of this discussion, it would be helpful if you point out an EE implementation that does replicate "transaction in-progress" state. I would like to point out that the unsaved changes associated with the extended persistence context are not saved to the database until a JTA transaction is associated with the extended persistence context. At the end of the transaction commit, the changes are in the database. If the database transaction rolls back, the changes are discarded (entities are detached). The reason that I bring this up, is that EJB passivation will not happen if there is a JTA transaction present. Which leaves us (IMO) with the above question about clustering implementations that have the ability to replicate "transaction in-progress" state. JPA 2.0 specification 7.9.1: [quote] ... For stateful session beans with extended persistence contexts: ... * When a business method of the stateful session bean is invoked, if the stateful session bean uses container managed transaction demarcation, and the entity manager is not already associated with the current JTA transaction, the container associates the entity manager with the current JTA transaction and calls EntityManager.joinTransaction. If there is a different persistence context already associated with the JTA transaction, the container throws the EJBException. * When a business method of the stateful session bean is invoked, if the stateful session bean uses bean managed transaction demarcation and a UserTransaction is begun within the method, the container associates the persistence context with the JTA transaction and calls EntityManager.joinTransaction. [quote] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-162: ----------------------------------- you would need a EE container anyway as an Type.EXTENDED EM is still container managed and NOT a native JPA EntityManager. I personally don't like to import broken patterns. But I have no strong feeling about it. It's broken on a higher level, so we cannot do anything against it anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira