I'm looking hard at WF 4.0 right now, but I'm having a hard time figuring out how to run workflows in STA threads. I've got a requirement for constructing XPS documents in a workflow, which means I need to create UI elements (FixedPage), which means the thread running the workflow has to be STA.
In 3.0, you could do some magic (I didn't manage this part of the code, so no details here) with the ManualWorkflowSchedulerService to get the workflow running in a STA thread. But now 4.0 is much different; even beta 2 is different from beta 1...
Anybody know how to get 4.0 workflows running in STA threads?
I can't use the WorkflowInvoker because it is only for short-lived workflows that don't require persistence, which I do.
Have you tried using the WorkflowInvoker? This should just execute the workflow on the original thread and not schedule work on a background tread.
Related
Maybe it's a simple question, but I don't get it. When should I use concureency in my javafx project? Is it right that I should use for every task, which do some action in the background, the Concurrency API? So every action in my controller class, which has nothing to do with the UI should be executed in a single task?
I really don't get it how to use this right....
Whenever you have a task that may take sometime to get executed or there is a possibility of delayed response, you do not want your JavaFX Application thread to wait for it, because, as long as the JavaFX Application thread waits for the response, the UI becomes unresponsive.
A few examples where you may want to use a background thread is :
An I/O operation
A web service call
From the JavaFX documentation :
Implementing long-running tasks on the JavaFX Application thread inevitably makes an application UI unresponsive.
On the other hand, if you have minor calculations or some task which can be completed in a jiffy (I am not sure if this is the correct word, but I hope you can relate to what I want to say) and will not put the JavaFX Application thread on wait, you can execute them on the same thread.
So I have some Java code that takes some time to complete (about 2 minutes). Nothing I can do about that.
But I am wondering how best to approach this in the XPages UI so that the user may still have to wait but has more control/interaction while it is running (not just a spinning wheel).
So from what I can see I can do the following.
Java class called in XPage wrapped in a thread.
Java Agent called from XPage in a thread.
Java Agent called from an XPage, but waits for a document to be updated.
Eclipse plugin (For in the client) is activated. Not sure how it would talk back to XPage though (via document?).
Any other methods?
If you created the thread in the XPage, is that going to cause any problems at the server end? Will I have to avoid using Notes objects in the Java class?
I would suggest using the OSGi Tasklet service, a.k.a. DOTS. This approach allows Java tasks to be scheduled or bound to events, just like agents, but perform significantly more efficiently than agents. Perhaps most pertinent to your need is the additional ability to trigger DOTS tasks via the console, which would allow your XPages code to start the Java code merely by issuing a remote console command via the session object.
In addition, check out the technique used in the XSP Starter Kit to provide a serverScope variable. If your code is running in a DOTS task (or even an agent), it's running in a different Java application, so it can't talk directly to the standard scope variables. The serverScope approach would theoretically allow you to store objects that can be accessed from both the XPage and the triggered task. This could aid in using Mark's technique, as mentioned above by Per, to convey progress to the user while the task is running: you'd just be storing the progress information in serverScope instead of sessionScope.
A solution would be to have an agent react on saving new documents in the database instead of kicking of the agent in your application and use threads ( because threads can be very dangerous and could easily kill your http task )
Another thing you could look into is why the code that you want to execute is taking 2 minutes to complete. What is the code for? Doing things in other databases or connect to other non notes resources?
I am developing an application level VSTO 4 Addin for Microsoft Excel 2007 / 2010.
The result is a windows forms based DLL using .Net 4 Client Profile.
Now I have to use a legacy COM-DLL. It is no problem to set the reference and access the COM-Methods via COM-Interop from .Net.
But the the (synchronous) method I need to call can take a minute or longer to get back.
I know your answer:
Use a worker thread...
I have used The Task Parallel Library to put the long lasting operation in a worker task and keep the GUI (Excel) responding.
But: The inprocess COM-Call (in the worker task/thread) still seems to block my GUI-Thread.
Why? Is it because Excel is always running as STA (Single Thread
Apartment)?
How can I keep the Excel GUI responding?
Is there a way to make it really asynchronous?
Thanks for any answers,
Jörg
Finally, I've found an answer to this topic:
I've readed a lot about COM Threading Models and then spoke to the developer of the COM-DLL I am calling as an InProc-Server.
Together we changed the threading model of the COM-DLL:
OLD (blocking): Single-Threaded Apartment (STA), (ThreadingModel=Apartment)
NEW (working): Multi-Threaded Apartment (MTA), (ThreadingModel=Free)
Since we have our own synchronization mechanisms in the COM-DLL, there are no problems caused by the missing synchronization via the standard Windows message queue.
Problem was, that even the UI Thread was idle and even if it did DoEvents, the important windows messages (WM_Paint, etc.) were not delivered.
Now they are. The UI is responding at every time and the call to the COM-DLL is still done in a worker thread (as mentioned above, it's a ThreadPool thread which is used by the Task Parallel Library).
I was hoping someone could point me in the right direction as far as how to run background task in Outlook 2007 while preserving a good User experience. I have a process that loops through each item in a default Outlook calendar and sends information (subject, location, etc.) to a back-end server. I have tried ThreadPool.QueueUserWorkItem and creating a Thread and setting it isBackground to true, but the User experience of normal operation in Outlook while this task is running seems to be compromised. Ideally I would like for this background task to run and not have Outlook seem sluggish. Any thoughts on how I could achieve this?
Thanks
Running background threads in out are not recomended, it can be done but it depends on what you are actualy doing in your code, The OOM is run in a single threaded apartment COM server, so every COM call is executed on the main thread of outlook.exe
From you description the best bet would be to process the items not using the OOM.
If you are running Exchange (dependant on the version) you can use EWS or ExchangeDav.
Otherwise MAPI.
Marcus
Just wondering if anyone has had any trouble using a BackgroundWorker Thread in a site running under IIS 7 in Integrated Pipeline mode?
I am trying to use such a beast to update the database schema (admin function, obviously), and it works perfectly in Cassini, but when I deploy to IIS 7, the thread gets about one line of code in and silently ends. Is there a way to tell why a thread ended?
Thanks in advance.
It is probably an exception. Perhaps you're running with different set of rights between the two environments.
I don't know but I have to ask: why do you use BackgroundWorker in first place? Its main purpose is to ease the threading on UI elements.
Instead why don't you use a "normal" thread or any other non-UI mechanism?
You do not want to use BackgroundWorker, Thomas from ASP.NET team just posted some information about executing code in separate threads in ASP.NET: http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx