[JBoss jBPM] - Re: Threads and jbpm
by jcarlos_andia
Thanks for the response kukeltje.
I have this code for the timer:
| Calendar cal=Calendar.getInstance();
| BusinessCalendar bc=new BusinessCalendar();
| Duration duration=new Duration("60 seconds");
| Date dueDate=bc.add(cal.getTime(), duration);
|
| Delegation delegate=new Delegation("com.jotatech.vgrc.action.visual.MyActionHandler");
| delegate.setProcessDefinition(bpmProject);
|
| Action myAction=new Action(delegate);
| myAction.setName("[ACTION]");
| myAction.setProcessDefinition(bpmProject);
| bpmProject.addAction(myAction);
|
| Timer myTimer=new Timer();
| myTimer.setName("[TIMER] "+myState.getName());
| myTimer.setDueDate(dueDate);
| myTimer.setRepeat("3 seconds");
| myTimer.setRetries(3);
| myTimer.setGraphElement(myState);
| myTimer.setAction(myAction);
| myTimer.setProcessInstance(myProcesInstance);
|
| log.info("Adding a timer to state {0} with dueDate {1}...",myState,myTimer.getDueDate());
| jbpmContext.getServices().getSchedulerService().createTimer(myTimer);
|
And the action:
| public class MyActionHandler implements ActionHandler{
|
| private static final long serialVersionUID = -7574831777028763706L;
|
| @Logger
| private Log log;
|
| public void execute(ExecutionContext context) throws Exception{
| log.info("EXECUTING ...");
| System.out.println("EXECUTING ...");
| }
| }
|
The execute method is not called but the retries goes from 3 to 0 when the dueDate is reached. Any clue? I assign the timer to the processInstance, is there any way to assign it to a processDefinition?. Thanks in advance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128008#4128008
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4128008
18 years, 2 months
[JBoss Seam] - SFSB extended persistence context with manual flush mode mix
by gjeudy
Hi,
I have a SFSB:
@Stateful
| @Scope(ScopeType.CONVERSATION)
using an extended persistence context. I also enabled manual flush mode at the beginning on of the conversation.
@PersistenceContext(unitName="mypu",
| type=PersistenceContextType.EXTENDED)
| private EntityManager em;
@Begin(flushMode = FlushModeType.MANUAL)
During the conversation some calls are made to a DAO Service implemented as a SLSB.
@Stateless
| @Scope(ScopeType.SESSION)
This SLSB gets an entitymanager through this annotation:
@PersistenceContext(unitName=RDMConstants.RDM_PERSISTENCE_UNIT_NAME)
| private EntityManager em;
I am using CMT transactions with the default setting (which is transaction.REQUIRED) for both EJBs
The SLSB issues calls to em.merge(), em.remove(), etc.. However I noticed that the em is flushed as soon as the system transaction commits which is when we return from the SFSB method execution.
Even though each EJBs have it's own EM instance they are both using the same persistence context, would it be possible to inherit the flush mode set on the SFSB in the SLSB ? Right now the SLSB inherits the persistence context bound to the system transaction.
I am doing all this because I want to push all EM related operation to SLSBs and allow better re-usability. How can I achieve this with a manual flush mode ? I want to prevent automatic flush the end of every request. I also want to avoid hardcoding the SLSB to use a specific flush mode strategy.
One possible solution would be to never call the SLSB (EM methods) until the @End of the conversation. The SFSB would queue all pending updates in custom memory structures (List, Maps, etc..). These structures would be used to send all requests to the SLSB inside the method marked with @End annotation.
Alternatively I could do all EM operations inside the SFSB throughout the conversation and only em.flush() at the @End of the conversation, but then I would lose some re-usability because I cannot do EM operations in the SLSBs without seeing them committed at the end of the system transaction.
I hope I explained my usecase clear enough. What is the best practice in this scenario ? It seems that SEAM promotes a 1 layer approach where both business logic and persistence logic would sit inside the same SFSB. Please correct me if i'm wrong.
Thanks,
-Guillaume
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127992#4127992
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127992
18 years, 2 months