[EJB3] - Does a LockAcquisitionException Invalidate a Transaction?
by Sam Smith
Sam Smith [https://community.jboss.org/people/ssmith2010] created the discussion
"Does a LockAcquisitionException Invalidate a Transaction?"
To view the discussion, visit: https://community.jboss.org/message/729932#729932
--------------------------------------------------------------
We're using Hibernate with SQL Server. As you may know, SQL Server will occassionally throw deadlocks during SELECT statements. We'd like to be able to capture this exception and retry the SELECT statement. Our preference would be to do this globally in our EJB (which ises CMP), something like this:
{code}
public List getData(args...)
int retries=0;
boolean continue=true:
while (continue) {
try
continue = false;
{
hibernate query to SELECT data
}
catch (Exception ex)
{
if (ex instanceof LockAcquisitionException) {
retries++;
if (retries < 5) continue = true;
}
}
}
{code}
So the idea is to do the query, if there's a LockAcquisitionException, just retry a couple of time. Our only concern is this -- does the exception invalidate the transaction? We know the transaction is started when we enter the method, so if within the method we get an error, can we just retry or is the transaction no longer any good? I'm sure it would be no good if we were doing an update and it forced a ROLLBACK, but we're unsure about in a non-update statement.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/729932#729932]
Start a new discussion in EJB3 at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 12 months
[EJB3] - Re: EJB thread not interrupted after transaction timeout
by Bob Kung
Bob Kung [https://community.jboss.org/people/r4_1314] created the discussion
"Re: EJB thread not interrupted after transaction timeout"
To view the discussion, visit: https://community.jboss.org/message/729820#729820
--------------------------------------------------------------
So far I havn't found any elegent solution, however, I have a workaround, though it will introduces non-business code into your MDB.
1) Inject EJBContext to your MDB
2) Use ejbContext.getRollbackOnly() method to check whether the current transaction already rollback before continue process. If current transaction has been canceled, skip the following process till the end.
This solution should be safe in only database operating situation, meanwhile there still has a drawback for this solution. Please look at the following situation.
1) The some operations to a share resource which is not rollbackable, such as writing strings to a file in this transaction.
2) Redelivery Delay is 0 and Max Delivery Attempts more than 1
Once the transaction timeout, JMS will redeliver the message, but the previous message still on processing which is writing strings to a file. At this time, the file is operating by 2 threads and this may cause error. So it should be considered how to handle the resource conflict in this case.
Am I missing sth? please comment.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/729820#729820]
Start a new discussion in EJB3 at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 12 months
[jBPM] - persistent state of process and resume of process
by Rudi Fisher
Rudi Fisher [https://community.jboss.org/people/rudi_fisher] created the discussion
"persistent state of process and resume of process"
To view the discussion, visit: https://community.jboss.org/message/729791#729791
--------------------------------------------------------------
I have a situation where I need to resume process execution after restart of jBPM (restart of JBoss). I'm working with work item handlers and I want to have possibility to resume of execution of asynchronous work item handlers. Everything is working fine for my implementation if jBPM is running but problem is if I restarted jBPM (JBoss).
Situation is:
I implemented "go to shutdown" functionality which works in this way: if "go to shutdown" global attribute of system is set, then at the begining of method executeWorkItem return is called and work item is not executed at all. This means no work item is executed if this attribute is set in my system. Also no new process can't be created or started. After while all process are in wait state and state of processes is persisted.
After this JBoss is restarted.
Then I'll turn off "go to shut down" atttribute and call my resumeProcesses functionality. This functionality will takes all not finished work items from WorkItemInfo table and call executeWorkItem for every work item. This will cause that body of work item'll be executed and if success method completeWorkItem will be executed. This works if JBoss is not restarted but if JBoss is restarted, workitem is completed but process doesn't continue with execution of next node.
I'm confused because this is working if Jboss is not restarted so this means that process is not persisted "correcly". I found where is the problem. After JBoss is restarted every processInstace which is going to use have to be read from persisted state - see AbstractProcessInstanceMarshaller.readProcessInstance. In this method reconect method is called where correct listeners are added for all node instances, but I'm confused that there is a previous node used, not node of my last work item. This will cause that there are added only listeners for my previous work item which was already succesfully completed. This is difference if Jboss is not restarted because process instance is not loaded from persistent state and is used from session and there is corrrect node.
Is this how process persistence should work or is this some bug or I'm missing something about this. Thank you for any advice.
Another plan is to modify process somehow in runtime and add event to wait for signal to achieve this resume functionlity but i think this is not a good idea.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/729791#729791]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
13 years, 12 months
