[jBPM Development] - org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction
by Siddhesh M
Siddhesh M [http://community.jboss.org/people/siddhesh27] created the discussion
"org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction"
To view the discussion, visit: http://community.jboss.org/message/636462#636462
--------------------------------------------------------------
Hi ,
I am using JBPM 4.3. I can see following exception in production env.
<Nov 12, 2011 3:03:10 PM CET> <Notice> <Stdout> <BEA-000000> <12-Nov-2011 15:03:10.576 | ERROR | DispatcherThread | .AbstractFlushingEventListener | Could not synchronize database state with session
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.pvm.internal.model.op.ExecuteActivityMessage#683270098]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1792)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2435)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2335)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2635)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88)
at weblogic.transaction.internal.ServerSCInfo.doBeforeCompletion(ServerSCInfo.java:1224)
at weblogic.transaction.internal.ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:1199)
at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:118)
at weblogic.transaction.internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:1310)
at weblogic.transaction.internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:2126)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:266)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:233)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:286)
at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:280)
at org.jbpm.pvm.internal.tx.JtaTransaction.commit(JtaTransaction.java:104)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.executeInNewTx(JtaTransactionInterceptor.java:89)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:66)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.executeWithRetry(JtaRetryInterceptor.java:52)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.execute(JtaRetryInterceptor.java:45)
<Nov 12, 2011 3:03:10 PM CET> <Notice> <Stdout> <BEA-000000> <12-Nov-2011 15:03:10.579 | ERROR | DispatcherThread | l.jobexecutor.DispatcherThread | excep
tion in job executor thread. waiting 5000 milliseconds
org.jbpm.api.JbpmException: couldn't rollback: Transaction does not exist
at org.jbpm.pvm.internal.tx.JtaTransaction.rollback(JtaTransaction.java:96)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.executeInNewTx(JtaTransactionInterceptor.java:92)
at org.jbpm.pvm.internal.tx.JtaTransactionInterceptor.execute(JtaTransactionInterceptor.java:66)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.executeWithRetry(JtaRetryInterceptor.java:52)
at org.jbpm.pvm.internal.tx.JtaRetryInterceptor.execute(JtaRetryInterceptor.java:45)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.acquireJobs(DispatcherThread.java:126)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.run(DispatcherThread.java:67)
Caused by: java.lang.IllegalStateException: Transaction does not exist
at weblogic.transaction.internal.TransactionManagerImpl.rollback(TransactionManagerImpl.java:301)
at weblogic.transaction.internal.TransactionManagerImpl.rollback(TransactionManagerImpl.java:296)
at org.jbpm.pvm.internal.tx.JtaTransaction.rollback(JtaTransaction.java:94)
... 10 more>
Anybody has any clue.
What I have noted is though above exception is comming my workflow get completed successully. What I think two different thread trying to access same data , one successufully updates the data and which is why the workflow gets completed , but the other one keeps retrying for many times. Please let me know any solution to such race condition.
Thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/636462#636462]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
[JBoss AS7 Development] - Infinispan Subsystem Management API
by Richard Achmatowicz
Richard Achmatowicz [http://community.jboss.org/people/rachmato] modified the document:
"Infinispan Subsystem Management API"
To view the document, visit: http://community.jboss.org/docs/DOC-17351
--------------------------------------------------------------
h1. Notes on the Infinispan subsystem management API
This document aims to present an overview of some of the issues involved in the design/implementation of the Infinispan management API for AS7.
h2. 0. Background
h6. Services
The Infinispan subsystem of AS7 is made up of the following:
* a runtime, namely a collection of Modular Service Container (MSC) service instances (EmbeddedCacheManagerService, CacheService and EmbeddedCacheManagerDefaultsService) providing Infinispan-related services to the AS as a whole
* a persistent configuration of the subsystem in standalone.xml (or domain.xml) describing the configuration of the various services
* services upon which the Infinispan subsystem is depeneent (e.g. JGroups services, transaction services, naming services, etc)
h6. Management of services
The management API allows defining addressable resources (entities with attributes and operations) to represent these elements of the Infinispan subsystem and allow the user to interact with them. It also allows specifying what needs to happen in response to any user interaction with the subsystem elements. For example, if we change a configuration attribute of a service, a restart of that service may be required.
The key questions to be decided are:
* what do we want users to be able to do with the management API when interacting with the Infinispan subsystem? (add cache manager instances? add cache instances? add new configurations only? change an existing configuration?)
* how do we want them to be able to do it? (e.g. add a cache configuration with a single operation execution, or over multiple operation executions)
* how are we going to deal with the impact of their actions on the running system? (e.g. are restarts of some or all services required upon operation execution?)
Another consideration is that the "final" functionality of the Infinispan management API will probably evolve over several releases as requirements are established.
h2. 1. Proposed scope of initial release
The following provides a summary of the proposed features to be included in the inital version of the managemnt API for Infinispan and provides some discussion of related issues.
h3. 1.1 Initial Features
A user should be able to do the following from the management API (either programmatically or via CLI):
* cache manager operations* add a new configured cache manager to the system
* remove an existing cache manager from the system
* cache operations* add a new configured cache to the system, under the control of an existing cache manager
* remove an existing cache from the system
* MBean style access to operations and attributes* provide read-only access to cache managers, caches and ancillary components (see http://docs.jboss.org/infinispan/5.1/apidocs/jmxComponents.html http://docs.jboss.org/infinispan/5.1/apidocs/jmxComponents.html)
h3. 1.2 Useability Issues
The Infinispan subsystem is initially started from a persistent configuration in XML (i.e. see <subsystem xmlns="urn:jboss:domain:infinispan:1.0"/> in standalone.xml). This configuration describes the cache manager instances and their cache instances which will be installed as services in thye Infinispan subsystem. In addition, each cache manager and cache element specifies overrides to the clustering-specific default values for many (but not all) cache manager and cache configuration settings. Configuration of this initial state system state via XML is simple.
Providing the same configuration ability from the command line is less easy. Some issues:
1. *handling cache manager/cache definitions* - cache manager and cache definitions are large in size (and getting larger) and contain many nested elements. Inputting a cache definition from a command line in one operation execution presents problems; in particular, how to represent nested attributes.
2. *separating cache manager/cache definition from cache manager/cache start* - do we define and start the cache manager/cache in one operation, or define and start separately. In the initial startup from XML, services are defined and started in one shot.
3. *separate cache definitions* - in the current XML, cache manager/cache service instances are tied to their definitions. Being able to reference a definition when starting a cache could be useful. (possibly in later release)
h3. 1.3 Issues concerning effect of management operations on runtime
Each management operation has the potential to affect both the persistent configuration of the subsystem on disk as well as the current runtime state of the services. In particular, making changes to the persistent configuration of a running service may necessitate the restart of the service itself and other services in the system. For example, changing the transport of a cache manager from stack="udp" to stack="tcp" wiil requie retsrating the cache manager, the caches it contains as well as the applications which depend on those caches. Changing other cache manager attributes may not be so intrusive.
To handle these situations, the management API provides an attribute "restart-required" for operations which can affect the runtime state and will indicate to the user the appropriate restart actions. Possible values are:
* no services - applying the operation to the runtime does not require the restart of any services
* all-services - applying the operation to the runtime requires a restart of all services in the system before it will take effect (e.g. via management command /:reload)
* jvm - applying the operation to the runtime requires a restart of the entire JVM before it will take effect (e.g. via management command /:shutdown followed by command line startup)
* resource-services - applying the operation to the runtime will generally require a restart of all services in the system except if the operation specifies "allow-resource-service-restart" => true, in which case the operation may restart any services required "on-the-fly"
So, with respect to management commands we provide, there are issues:
1. *CacheManager and Cache restart requirements*- what are the general restart requirements for CacheManager and Cache instances when we change their configurations on-the-fly?
2. *determining restart requirements and policy for specific operations* - for each operation, we need to be aware of its restart requirements and the intrusiveness on the system
For example, it should be possible to add a new cache manager to the system without restarting existing cache services. On the other hand, modifying an existing cache manager may or may not require a restart of that cache manager and its caches. Removing a cache should probably not require restarting the associated cache manager.
h2. 2. Addressable resources
The current plan is to make the following addressable resources, where cache resources are organized by cache mode:
<!-- Infinispan subsystem -->
/subsystem=infinispan
<!-- cache containers (with appropriate attributes, operations)-->
/subsystem=infinispan/cache-container=X
<!-- caches by type (with appropriate attributes, operations) -->
/subsystem=infinispan/cache-container=X/local-cache=Y1
/subsystem=infinispan/cache-container=X/invalidation-cache=Y2
/subsystem=infinispan/cache-container=X/replicated-cache=Y3
/subsystem=infinispan/cache-container=X/distributed-cache=Y4
<!-- cache components (with appropriate attributes, operations) -->
/subsystem=infinispan/cache-container=X/component=rpcmanager
/subsystem=infinispan/cache-container=X/component=transactionmanager
/subsystem=infinispan/cache-container=X/component=...
In the case of cache-containers and caches, the basic operations are add, remove and read-atribute, write-attribute.
h2. 3. Dealing with large configurations
There are two approaches possible for adding / removing configured cache managers and caches which differ in the way that configuration options are specified:
* single-step configuration, where the cache manager (resp. cache) is created, configured and started on demand in one step by passing all configuration settings as paranmeters to the add command
* multi-step configuration, where a cache manager (resp. cache) is created, configured and started in multiple steps
h3. Single-step configuration
In this approach, in a single step, the cache manager (resp. cache) is:
* created
* configured
* installed as a service and started on demand
Nested configuration elements are flattened (prefixed by their enclosing element name) so that they may be spefied on the command line.
<!-- add a new cache container named X (with top-level and nested configuration attributes specified) ->
/subsystem=infinispan/cache-container=X:add(default-cache=default, listener-executor=W, transport.stack=udp, transport.lock-timeout=100)
There is a problem with cache stores with this approach: cache stores can have nested lists of properties of the form <property name="X">Y</property> which are difficult (impossible) to represent with the flattened elements approach and the managemnt interface's requirements for parameter descritions. An alternative is to pass a complex structure representing the property list:
<!-- add a new cache container named X (with top-level and nested configuration attributes specified) ->
/subsystem=infinispan/cache-container=X/local-cache=Y:add(file-store.relative-to="/tmp", file-store.path="blah", store.properties={"X"="x", "Y"="y", ...})
This can then be parsed and setup as required.
h3. Multi-step configuration
In this approach, in individual steps, the cache manager (resp. cache) is:
* created but not installed nor started (the model is updated though)
* configured but not installed nor started (the model is updated though)
* installed as a service and started on demand
Nested configuration elements are available as addressable resources under the submodel name configuration=<element name> and attributes can be set using write-attribute.
<!-- create a new cache container but do not start it -->
/subsystem=infinispan/cache-container=X:add(default-cache=Y, jndi-name=Z)
<!-- for top-level cache container attributes (i.e. attributes of XML element cache-container), set them via write-attribute -->
/subsystem=infinispan/cache-container=X:write-attribute(name=jndi-name, value=W)
<!-- for nested nested cache-container attributes (i.e. attributes of child-elements of cache-container), access them as an addressable resource and seth them via write-attribute -->
/subsystem=infinispan/cache-container=X/configuration-group=transport:write-attribute(name=stack, value=udp)
/subsystem=infinispan/cache-container=X/configuration-group=transport:write-attribute(name=lock-timeout, value=100)
<!-- once configuration is done, start the cache container-->
/subsystem=infinispan/cache-container=X:start(mode=on-demand)
The idea behind this approach is to update only the model for all operations but start. For the operation start, read the model to build the runtime services and install them on demand.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17351]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 1 month
[JBoss AS7 Development] - Logging Id's
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging Id's"
To view the document, visit: http://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *CLI
* |
|
| *10600 - 10699* | *Controller Client* | W |
| *10700 - 10799* | *CMP* |
|
| *10900 - 10999* | *Domain Controller* |
|
| *11000 - 11099* | *EE* |
|
| *11100 - 11199* | *Embedded* | W |
| *11200 - 11299* | *JAXRS* | W |
| *11300 - 11399* | *JMX* | W |
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi (as plugin 00-10; service 11-99)* | C |
| *12000 - 12099* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *13100 - 13199* | *Security* |
|
| *14100 - 14399* | *Ejb3* | I |
| *14400 - 14499* | *AppClient* | C |
| *14500 - 14599* | *JDR* | C |
| *14600 - 14899* | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | C |
| *15000 - 15099* | *Deployment Scanner* | C |
| *15100 - 15199* | *Deployment HTTP API* | C |
| *15200 - 15299* | *Deployment Management* | C |
| | *EE Deployment* |
|
| | *Host Controller* |
|
| | *Jacorb* |
|
|
| *JAXR* |
|
|
| *JDR* |
|
|
| *Mail* |
|
|
| *Platform MBean* | |
|
| *POJO* |
|
|
| *Remoting* |
|
|
| *SAR* |
|
|
| *Security* |
|
|
| *Server* |
|
|
| *Threads* | |
|
| *Web* | |
|
| *Web Services* | |
|
| *Weld* |
|
|
| *Xts* |
|
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 1 month
[JBoss Web Services Development] - Where can I find the nightly build?
by Ramesh Reddy
Ramesh Reddy [http://community.jboss.org/people/rareddy] created the discussion
"Where can I find the nightly build?"
To view the discussion, visit: http://community.jboss.org/message/636291#636291
--------------------------------------------------------------
Hi,
Where can I find the nightly build for the JBossWS-CXF? I checked the Hudson build but did not see/or did not recognize the right name. Also on the your main page, for 4.0.0 beta builds, you have mentioned, the builds are in "maven2" as usual. I am not where that is. I have checked in the Jboss nexus, I found this
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo...
But I am looking for installable binary into AS7. Can you please point me to it?
Also, CXF Bus instance seems to be always depends on the Spring framework, so why not install it in the module always in AS7? I tried re-arranging and making dependency on "org.jboss.ws.cxf.jbossws-cxf-client" module and also tried adding JbossWS based bus factory service in the class path, but it still fails with Spring framework dependency. By making it available always, one can avoid one more install.
Thanks
Ramesh..
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/636291#636291]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 1 month
[JBoss AS7 Development] - Logging Id's
by James Perkins
James Perkins [http://community.jboss.org/people/jamezp] modified the document:
"Logging Id's"
To view the document, visit: http://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *
* |
|
| *10600 - 10699* | *Controller Client* | W |
| *10700 - 10799* |
|
|
| *10900 - 10999* |
|
|
| *11000 - 11099* | *EE* |
|
| *11100 - 11199* | *Embedded* | W |
| *11200 - 11299* | *JAXRS* | W |
| *11300 - 11399* | *JMX* | W |
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi (as plugin 00-10; service 11-99)* | C |
| *12000 - 12099* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *13100 - 13199* | *Security* |
|
| *14100 - 14399* | *Ejb3* | I |
| *14400 - 14499* | *AppClient* | C |
| *14500 - 14599* | *JDR* | C |
| *14600 - 14899* | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | C |
| *15000 - 15099* | *Deployment Scanner* | C |
| *15100 - 15199* | *Deployment HTTP API* | C |
| *15200 - 15299* | *Deployment Management* | C |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years, 1 month
[JBoss AS7 Development] - Re: jboss7 quickstarts entitymanager injection question
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow] created the discussion
"Re: jboss7 quickstarts entitymanager injection question"
To view the discussion, visit: http://community.jboss.org/message/635602#635602
--------------------------------------------------------------
Robert,
For each separate datasource used in your application , there should be a separate persistence unit for that datasource.
> @PersistenceContext(unitName="PersistenceUnitForMyEmployeeDatasource"
> EntityManager emEmployee;
>
> @PersistenceContext(unitName="PersistenceUnitForMyAccountsDatasource"
> EntityManager emAccounts;
>
When you use the above emEmployee, you will be creating/retrieving/updating/deleting employee datasource related entities. When you use the above emAccounts, you will be dealing with the accounts datasource.
Currently, if you were to leave the unit name out (for either EntityManager), the first persistence unit definition found (in the application), will be used. There isn't any magic to make the right choice, between the two separate persistence unit definitions. If you have an application with only one datasource and persistence unit definition, you could leave the UnitName blank.
In my opinion, a best practice, is to always specify the unitName, as that will make it easier in the future, when you go from one Datasource to multiple. I always want to make the code easy to maintain for the future generation. Of course there are probably many applications that will always have just one Datasource and those applications are fine to leave the unitName blank.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/635602#635602]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 2 months