[JBoss jBPM] - Deadlock on sqlserver
by owensky
I am getting deadlock problems running against sqlserver, running with isolation level 2 (Read Committed). The same app runs ok against Oracle.
The problem occurs under load typically after a few hundred transactions
Dropping the isolation level to 1 (Read Uncommitted) stops the deadlocks (though naturally introducing the risk of dirty reads).
I'm running jbpm 3.1.2 (the same occurs on 3.1), SQL Server 2005 Standard Ed (same occurs on Express), sqljdbc 1.1.
Any suggestions or comments anyone?
Owen.
ERROR - JDBCExceptionReporter - Transaction (Process ID 58) was deadlocked on lock resources with another proce
ss and has been chosen as the deadlock victim. Rerun the transaction.
org.hibernate.exception.GenericJDBCException: could not initialize a collection: [org.jbpm.taskmgmt.exe.TaskMgmtInstance
.taskInstances#4377]
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:91)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:79)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1926)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:71)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:52
0)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeColl
ectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1627)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.AbstractPersistentCollection.readElementExistence(AbstractPersistentCollection.java:
142)
at org.hibernate.collection.PersistentSet.add(PersistentSet.java:162)
at org.jbpm.taskmgmt.exe.TaskMgmtInstance.addTaskInstance(TaskMgmtInstance.java:376)
at org.jbpm.taskmgmt.exe.TaskMgmtInstance.createTaskInstance(TaskMgmtInstance.java:104)
at org.jbpm.taskmgmt.exe.TaskMgmtInstance.createStartTaskInstance(TaskMgmtInstance.java:272)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999857#3999857
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999857
19 years, 3 months
[Security & JAAS/JBoss] - Re: Trust association and subject building for SSO
by ganesh_asha
Hi Anil,
Thanks a lot for instant reply and your interest.
Firstly queries about your first reply
Anil: You have talked about web layer and ejb layer. Well yes we do have separate interceptors for both layer but if I use form based authentication for web layer then the same user information is passed on to the ejb layer. I am looking for the same kind of solution that if I use the GenericHeaderBasedAuthentication for my web layer then the same information should be propagated to EJB layer. Update me if I am wrong.
Secondly you have talked about Jboss security layer and Jaas layer. Let us elaborate these terms for common understanding
Jboss security layer: the components which determine that the requested resource is protected or not and user is already authenticated or not. I am looking out for these components but not able to do so. Kindly provide information on the same that which components are doing this. Again update me if I am wrong.
And the Jaas layer: it is the login module and security manager, realm mapping interface implementation doing authentication and role mapping
Now coming back to the original problem, I can clearly envisage and divide the problem into two parts.
1.How to get user information (from user in form, basic authentication or from headers in Generic header based authentication) and put it into cache
2. Validate the user information and associate the roles
Way ahead for problem 1
Use the GenericHeaderBasedAuthentication or some other valve of tomcat and get the information from header rather then asking the user and cache it with the container.
Way ahead for problem 2
Modify the login module so that it don?t use the database but use the same information provided in headers for validation and role mapping.
Priority wise first we are implementing the solution for problem 2, as it is more critical and it can eliminate the use of DB/LDAP. Secondly we will solve the problem 1.
The information is detailed out so other users can also use the same without loosing time.
Thanks again for help.
Thanks & Regards,
Ganesh
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999856#3999856
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999856
19 years, 3 months