[EJB3] - How to reconcile CMPC and SMPC?
by Bojan Dolinar
Bojan Dolinar [http://community.jboss.org/people/bodzolca] created the discussion
"How to reconcile CMPC and SMPC?"
To view the discussion, visit: http://community.jboss.org/message/611536#611536
--------------------------------------------------------------
When using EJB and Seam, it's probably inevitable to end up with lots of EJBs that are components at the same time, some with container-managed persistent context, some with SMPC. Because it was easier to do (mostly since it precludes any kind of LazyInitializationException) our codebase ended up with lots of EJBs/components with SMPC, even the ones that are part of the data engine and are not always part of the JSF lifecycle (triggered jobs, WS, other services, etc.). The absence of this lifecycle is probably the reason for some strange behaviour since it's not clear what the session is scoped to. For example, sometimes the actionqueue just doesn't get cleaned up after commit, so performance of a job degrades quickly (every flush "flushes" every preceding change), not to mention the memory leak. Migration from Seam 2.0.1 to 2.2.1 was the start of a whole new problem: org.hibernate.StaleStateException because optimistic locking failed. Looks like actionqueue again is keeping some stale objects and decides to commit them, quite sporadically, for all I could find out.
I guess that in the absence of conversation the session doesn't get closed. The situation is alleviated by superseding SMPC with @PersistenceContext. But due to convoluted and numerous execution paths, I'm not allowed to even dream that I'm aware of all the side effects. LIE is just on the top of the list, because all the entities loaded by PC are detached sooner or later.
All this leads to two questions. First, what would be the best way to handle this situation? Is mocking the approapriate JSF life cycle phases safe? Is it possible to scope SMPC to transaction programmatically?
Second, what is the best way to handle this situation from the scratch, when you have that luxury? I didn't find anything addressing this exact problem and I'm sure I'm not the only one experiencing it. My personal approach would be to keep the seam layer as thin as possible. When I was not restricted by legacy code, it worked quite well, although I had to think carefully about LIE all over again. However, every book I've read so far advocates the exact opposite approach. Their samples are usually pure web applications, but I was more than welcome to the real world.
Any thoughts or pointers to further reading on this would be appreciated.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/611536#611536]
Start a new discussion in EJB3 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 7 months
[jBPM] - Querying Content Object
by Sridhar J
Sridhar J [http://community.jboss.org/people/sridhar532] created the discussion
"Querying Content Object"
To view the discussion, visit: http://community.jboss.org/message/635916#635916
--------------------------------------------------------------
1) Hi, We are able to launch the workflow and Complete Human Tasks in the Workflow successfully in jBPM 5.1. We have a requirement to perform a Search Operation on the Task to display the Tasks details Assigned to a User.
Say for Eg) For a Human Task we have a variable "AssignedTo" defined in the Workflow which will have a value entered by user "Username" when user Completes or Saves the Task. This Value currently gets Saved in the Content Object of jBPM. If i want to search by the given "Username" to retrieve the list of Task Assigned then let me know the options ?
2) Also secondly how to run any query on the variables declared in the Human tasks which are available inside Content Object.
3) Is it possible to retrieve the Session ID from the Task (Which Created it) in jBPM 5.1
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/635916#635916]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 7 months
[jBPM] - Re: Persisting Human Task, letting user to complete after server restart.
by Mauricio Salatino
Mauricio Salatino [http://community.jboss.org/people/salaboy21] created the discussion
"Re: Persisting Human Task, letting user to complete after server restart."
To view the discussion, visit: http://community.jboss.org/message/601635#601635
--------------------------------------------------------------
Hi Adam,
I think that you are mixing a lot of concepts here. Don't get me wrong, it usually happens. The concept of save point also includes Human Tasks. Human interactions are considered as long living activities. For that reason the engine need to wait until the task is completed. As you mention all this waiting happens in a database, so you don't need to be worried about the application is running or not. Obviously the task server needs to be up when the user cames back and want's to interact, but it doesn't mean that needs to be up all time. Right now in jBPM5, we keep two different things persisted.
1) A knowledge runtime snapshot (SessionInfo in the database)
2) The status of each particular task inside the task server.
The task server is configured to use persistence by default, but as far as I remember, it's configured to use an in memory database. You should go and change that to a real database like MySQL/Postgres.
For having persistence of your processes status, that you will need if you are using human tasks interactions you need to use JPAKnowledgeService helpers to keep your sessions persisted in a database.
Greetings.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/601635#601635]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 7 months
[JBoss Messaging] - ConcurrentModificationException at ChannelSupport.deliverInternal
by Markus Lutum
Markus Lutum [http://community.jboss.org/people/mclu] created the discussion
"ConcurrentModificationException at ChannelSupport.deliverInternal"
To view the discussion, visit: http://community.jboss.org/message/580205#580205
--------------------------------------------------------------
Hi out there.
We are using Messaging 1.4.5 GA and got twice this error in production at 2 different systems:
Any ideas about the problem? Should we update to 1.4.7?
It could be that we had a short network issue on that machine but application and database is on the same machine.
Also I whould not expect a concurrentModificationException if this happens. It the network the root cause and what happens with the system if this happend?
THX
Markus
15:36:11,000 WARN [org.jboss.jms.server.endpoint.ServerSessionEndpoint] No expiry queue has been configured so removing expired
Reference[23298596871307270]:RELIABLE
15:36:11,015 WARN [org.jboss.jms.server.endpoint.ServerSessionEndpoint] No expiry queue has been configured so removing expired
Reference[23298608005775380]:RELIABLE
15:36:11,015 WARN [org.jboss.jms.server.endpoint.ServerSessionEndpoint] No expiry queue has been configured so removing expired
Reference[23298608312483861]:RELIABLE
15:36:11,031 ERROR [org.jboss.messaging.core.impl.ChannelSupport] Queue[26556037/1/2-notifications_mediumretry] Failed to deliver
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(Unknown Source)
at java.util.LinkedList$ListItr.remove(Unknown Source)
at
org.jboss.messaging.util.prioritylinkedlist.BasicPriorityLinkedList$PriorityLinkedListIterator.remove(BasicPriorityLinkedList.java:295)
at
org.jboss.messaging.core.impl.ChannelSupport.deliverInternal(ChannelSupport.java:729)
at
org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:506)
at
org.jboss.messaging.core.impl.ChannelSupport.acknowledgeInternal(ChannelSupport.java:844)
at
org.jboss.messaging.core.impl.ChannelSupport.acknowledge(ChannelSupport.java:290)
at
org.jboss.messaging.core.impl.SimpleDelivery.acknowledge(SimpleDelivery.java:103)
at
org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:1109)
at
org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:236)
at
org.jboss.messaging.core.impl.RoundRobinDistributor.handle(RoundRobinDistributor.java:119)
at
org.jboss.messaging.core.impl.MessagingQueue$DistributorWrapper.handle(MessagingQueue.java:583)
at
org.jboss.messaging.core.impl.ClusterRoundRobinDistributor.handle(ClusterRoundRobinDistributor.java:79)
at
org.jboss.messaging.core.impl.ChannelSupport.deliverInternal(ChannelSupport.java:665)
at
org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:506)
at
org.jboss.messaging.core.impl.ChannelSupport.acknowledgeInternal(ChannelSupport.java:844)
at
org.jboss.messaging.core.impl.ChannelSupport.acknowledge(ChannelSupport.java:290)
at
org.jboss.messaging.core.impl.SimpleDelivery.acknowledge(SimpleDelivery.java:103)
at
org.jboss.jms.server.endpoint.ServerSessionEndpoint.expireDelivery(ServerSessionEndpoint.java:1109)
at
org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:236)
at
org.jboss.messaging.core.impl.RoundRobinDistributor.handle(RoundRobinDistributor.java:119)
at
org.jboss.messaging.core.impl.MessagingQueue$DistributorWrapper.handle(MessagingQueue.java:583)
at
org.jboss.messaging.core.impl.ClusterRoundRobinDistributor.handle(ClusterRoundRobinDistributor.java:79)
at
org.jboss.messaging.core.impl.ChannelSupport.deliverScheduled(ChannelSupport.java:763)
at
org.jboss.messaging.core.impl.ChannelSupport$DeliverRefTimeoutTarget.timedOut(ChannelSupport.java:1151)
at
org.jboss.util.timeout.TimeoutFactory$TimeoutWorker.run(TimeoutFactory.java:265)
at
org.jboss.util.threadpool.RunnableTaskWrapper.run(RunnableTaskWrapper.java:148)
at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:756)
at java.lang.Thread.run(Unknown Source)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/580205#580205]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
12 years, 7 months