In the project I’m working on I have a couple of windows used to prior to an operator running a machine. The first window is used to scan a work order via a barcode reader. The operator then hits a button, which is used to validate the work order number. It does this by utilizing Sepasoft Business Connector/SAP Interface to poll SAP for the work order information. Information from SAP is then placed into datasets tags that were created on the machine UDT. We then do some calculations to see if there are pieces available to be run for that specific machine. Part of the button script also performs a named query used to either insert/update the work order information in an MSSQL database. Their old system, which other machines are still using and we have not yet migrated, are writing to the same database. Sometimes the query being run is slow and causes the GUI to freeze. So I was thinking about invoking the execution of the named query asynchronously, as the verification of the storage of the data is not necessary for the operator to move to the next window (the list from the next window looks at the dataset tag). The execution of the named query is done in a FOR loop, so there would multiple (4-6) threads created.
The second window allows the operator to select the operation on the machine from a list. There is a button to submit the selection. Before the operator submits their selection, I’d like to make sure that the threads that were created from the original screen have completed as it needs the data that was stored from the original queries when it run a named query that runs a stored procedure to start a transaction record in SQL . My question is whether monitoring these threads programmatically is possible.
You would move your multiple queries to a background thread and then use invokeLater to report progress and delivery data back to the foreground. Swing has single-threading rules you must respect. See this topic:
Thanks. I did end up putting the SQL writes into separate background threads. I don’t believe we’ve seen the GUI freeze since we’ve done this. We still see some slow insert/update queries in the gateway log, but I believe that everything needs to be written to the database seems to have been written.
Instead of doing a simple RunNamedQuery in these scripts, is there any advantage to performing the database writes as transactions (as in beginNamedQueryTransaction)? I don’t really need any feedback on the insert/update queries, so the fact that commitTransaction and closeTransaction return nothing is not terribly concerning to me.
The usage of transactions is to make a set of insert/update/delete statements “atomic” ie either they all run or if one of them fails, none of them execute.
The easiest example I use now to explain transaction groups to non-IT is the usage of a credit/debit system. Say a company buys something and need to add journal entries to credit and debit accounts. There are three scenarios that could happen here 1) neither entry is entered 2) only a credit or only a debit entry is entered, but the other one is not, or 3) both entries are entered.
Situation 1 isn’t ideal but you’re account numbers will make sense, 3 is obviously preferred , but 2 is more damaging in this situation than situation 1 because now things will look out of balance and your data will be in a state that it shouldn’t be allowed in.
So if you want to make groups of inserts coupled together and atomic and they either all execute successfully or none of them do, then use transactions. If this is not important, than you will not be getting an additional benefit.
Anything related to a situation where user input triggers multiple inserts/update/delete statements, I definitely opt for them personally.