Weld, seam 3 and proper REQUIRES_NEW support for SMPC

[swd847]

One of the things that has always bugged me about seam is the way the the SMPC does not respect transaction boundaries. Would this be something that we can get fixed in seam 3?

Thinking about it I assume there is going to be a conversation scoped manager component that produces a @Dependent scoped entityManager. If this manager maintained a stack instead, and simply pushed a new entityManager onto the stack when a new transaction starts and pops it when the new transaction ends then this should solve the problem.

Can anyone see any issues with this design?

[asookazian]

Irrespective of the design/solution, the point is that it really needs to be solved b/c EJB and Spring both have more tx-mgmt capabilities (in terms of more robust tx propagation types) than Seam 2.x...

[gavin.king]

I don't think we would need to do a whole stack if we have a @TransactionScoped custom scope. Just not 100% sure if a transaction scope can be implemented in a truly portable way. Well, I suppose it can be for CMT. Perhaps not for BMT. But I suppose support for CMT might be good enough.

What I would like to have is this.

@Produces @ConversationScoped 
@PersistenceContext(type=EXTENDED) EntityManager em;

@Produces @TransactionScoped 
@PersistenceContext EntityManager em;

Or something like that.

[swd847]

But then you have to know if your bean is being used with a transaction scoped or conversation scoped entityManager in advance, so you can't have a bean that just does the right thing no matter where it is being used. e.g.

class MyEntitySetupBean
{
  @Inject EntityManager entityManager;

  public void setupAndSave(Entity e )
  {
    doSetup(e);
    entityManager.persist(e);
  }
}

In an ideal world I could just call this method and not have to worry about getting the right entity manager.

[swd847]

I don't think the lack of support for BMT's matters, if you are using BMT's you can just inject the EntityManagerFactory.

You could not make it work anyway, as transactions can stop/start in the middle of the method, and you can't change the injected object at that point.

[gavin.king]

You could not make it work anyway, as transactions can stop/start in the middle of the method, and you can't change the injected object at that point.

Yes you can, by proxying it.

[asookazian]

Gavin King wrote on Nov 18, 2009 05:50:


I don't think we would need to do a whole stack if we have a @TransactionScoped custom scope. Just not 100% sure if a transaction scope can be implemented in a truly portable way. Well, I suppose it can be for CMT. Perhaps not for BMT. But I suppose support for CMT might be good enough.

What I would like to have is this.

@Produces @ConversationScoped 
@PersistenceContext(type=EXTENDED) EntityManager em;

@Produces @TransactionScoped 
@PersistenceContext EntityManager em;

Or something like that.

So is the first code example above the equivalent of SMPC in Seam 2.x?  In other words, we have a tx-scoped PC, an extended component-scoped PC (both of which are part of EJB 3.x and/or JPA 2 I assume) and a conversation-scoped PC which may include many components during the LRC.

And then the assumption is that it's a best practice to continue to use SMPC (example 1 above) and Hibernate manual flush for all LRC-modeled use cases?

[pmuir]

Arbi Sookazian wrote on May 07, 2010 23:04:

Gavin King wrote on Nov 18, 2009 05:50:


I don't think we would need to do a whole stack if we have a @TransactionScoped custom scope. Just not 100% sure if a transaction scope can be implemented in a truly portable way. Well, I suppose it can be for CMT. Perhaps not for BMT. But I suppose support for CMT might be good enough.

What I would like to have is this.

@Produces @ConversationScoped 
@PersistenceContext(type=EXTENDED) EntityManager em;

@Produces @TransactionScoped 
@PersistenceContext EntityManager em;

Or something like that.

So is the first code example above the equivalent of SMPC in Seam 2.x?  In other words, we have a tx-scoped PC, an extended component-scoped PC (both of which are part of EJB 3.x and/or JPA 2 I assume) and a conversation-scoped PC which may include many components during the LRC.

And then the assumption is that it's a best practice to continue to use SMPC (example 1 above) and Hibernate manual flush for all LRC-modeled use cases?

Yes.

[asookazian]

I will miss the simpler: @In EntityManager em; syntax.  Although there is a difference b/n injection and a producer method obviously.

Is there any way to replace @Produces @ConversationScoped @PersistenceContext(type=EXTENDED) with a single annotation.  Is that possible with stereotypes or other CDI construct (read the spec ;)?

[pmuir]

Arbi Sookazian wrote on May 19, 2010 18:02:


I will miss the simpler: @In EntityManager em; syntax.  Although there is a difference b/n injection and a producer method obviously.

Is there any way to replace @Produces @ConversationScoped @PersistenceContext(type=EXTENDED) with a single annotation.  Is that possible with stereotypes or other CDI construct (read the spec ;)?

@Produces @ConversationScoped @PersistenceContext(type=EXTENDED) is equivalent to your components.xml declaration of the SMPC. To use it you would still just do @Inject EntityManager em;.