Dynamics AX Threads - More details
Recently, I wrote a post about making use of Threads in X++ development, for Dynamics AX. A direct link to that post can be found here.:
Dynamics AX 2009 - X++ Thread Development
In the above post, I went over the Thread class, as an intro really, showing how to create a method that would be executed from a spwaned thread, and a job that kicks such a thread off for working with Sales Order data.
Again, the idea with that post was to really show what Threads can do, get you thinking about threads, and also some limits I ran into, with trying to spawn multi level threads, within threads.
With this post, I wanted to give a little more information about working with threads, covering thread statuses and also the worker process users that show up in the online users form.
So, if you create a new instance of the Thread class, you will notice a method called, Thread.Status(). This method returns an int based value. There is really no documentation on what these values mean, so I dug a little deeper into this.
In doing so I found out the following values, as returned from a call to Thread.Status().:
Now why would understanding these thread status values be important? Well with thread development, you have to have code that acts as the thread manager. In most cases, when your doing thread development, you are spawning more than one thread at a time. This means you need to know, for your given section of code, when all the spawned threads are finished.
Once you know all your spawned threads are completed, then you can move on in your host code, to continue and finish out whatever process is taking place.
So with the Thread Status value, you can make use of say an Array or a Map object to store the referenced spawned threads, and use that in RAM object to manage the threads, until they are all completed.
Now having multiple threads spawned, brings me to the next area I wanted to cover in this post, which is the 'Worker Process' type users you might see in the online users form.
If you notice these, possibly one per thread spawned, you will see that it seems to act like a license is being used. However, look at the active users total on the online users form and you will note the number of active users does not increase, when a worker process user is listed.
This is good news, as it would seem worker process user types, do not take up a license.
You still need to be careful and control the amount of spawned threads, as you could spawn way to many for the system to really handle. Depending on the load and actual work be performed by the Threads.
One other note about the worker process, is you will see these when you spawn the threads from a client session. Even though the thread is executing a server side static method. However if the given host code / business logic, that does the thread spawning is executed in Batch mode for example. You will not see the worker processes appear in the online users form.
So with this, we have a little better knowldge about Threads, thread status, it use with thread management, and understanding of the worker process user type.
That's all for now, but I have more post coming, so check back soon!
"Visit the Dynamics AX Community Page today!"
Dynamics AX 2009 - X++ Thread Development
In the above post, I went over the Thread class, as an intro really, showing how to create a method that would be executed from a spwaned thread, and a job that kicks such a thread off for working with Sales Order data.
Again, the idea with that post was to really show what Threads can do, get you thinking about threads, and also some limits I ran into, with trying to spawn multi level threads, within threads.
With this post, I wanted to give a little more information about working with threads, covering thread statuses and also the worker process users that show up in the online users form.
So, if you create a new instance of the Thread class, you will notice a method called, Thread.Status(). This method returns an int based value. There is really no documentation on what these values mean, so I dug a little deeper into this.
In doing so I found out the following values, as returned from a call to Thread.Status().:
- 0 = Thread never ran
- 1 = Thread is executing
- 2 = Thread has finished executing
Now why would understanding these thread status values be important? Well with thread development, you have to have code that acts as the thread manager. In most cases, when your doing thread development, you are spawning more than one thread at a time. This means you need to know, for your given section of code, when all the spawned threads are finished.
Once you know all your spawned threads are completed, then you can move on in your host code, to continue and finish out whatever process is taking place.
So with the Thread Status value, you can make use of say an Array or a Map object to store the referenced spawned threads, and use that in RAM object to manage the threads, until they are all completed.
Now having multiple threads spawned, brings me to the next area I wanted to cover in this post, which is the 'Worker Process' type users you might see in the online users form.
If you notice these, possibly one per thread spawned, you will see that it seems to act like a license is being used. However, look at the active users total on the online users form and you will note the number of active users does not increase, when a worker process user is listed.
This is good news, as it would seem worker process user types, do not take up a license.
You still need to be careful and control the amount of spawned threads, as you could spawn way to many for the system to really handle. Depending on the load and actual work be performed by the Threads.
One other note about the worker process, is you will see these when you spawn the threads from a client session. Even though the thread is executing a server side static method. However if the given host code / business logic, that does the thread spawning is executed in Batch mode for example. You will not see the worker processes appear in the online users form.
So with this, we have a little better knowldge about Threads, thread status, it use with thread management, and understanding of the worker process user type.
That's all for now, but I have more post coming, so check back soon!
"Visit the Dynamics AX Community Page today!"
Labels: Code Example, Dynamics AX 2009, Thread Development, Threads, X++
1 Comments:
Great! it's what i'm looking for. Many thanks!
Now i'm testing Threads to insert large amount of data in General Journal. I'm looking for the number of threads that reach the best performance...
I'll tell you when I finish.
Post a Comment
<< Home