How can a UniAlerter be used in multiple threads without Synchronize?
Especially for sending and receiving database events. In the receiving event a TUniQuery is used with the same TUniConnection as the TUniAlerter. That means the TUniAlerter.OnEvent have to run in the same thread and not in the main application thread. I 've noticed that TUniAlerter.OnEvent is fired in the main application thread and not in the expected thread.
Because the thread is time critical a synchronize with the main application thread is not an option.
UniAlerter and threads
Re: UniAlerter and threads
The TUniAlerter.OnEvent call using the Synchronize method is implementation specificity in UniDAC.
However, you can leave your suggestion about implementing alert mechanism in UniDAC without using the Synchronize method at our UserVoice ( http://devart.uservoice.com/forums/1046 ... components ). If the suggestion gets enough votes, we will consider the possibility of its implementation.
However, you can leave your suggestion about implementing alert mechanism in UniDAC without using the Synchronize method at our UserVoice ( http://devart.uservoice.com/forums/1046 ... components ). If the suggestion gets enough votes, we will consider the possibility of its implementation.
Re: UniAlerter and threads
Thx for your reply
An other UniDac specifcity is that everything is very thread critical. E.g. see viewtopic.php?f=28&t=34740&p=121147#p121147
Both specifities don't match and are imposed by UniDac what results in problems. So, we are not talking about a request to asuggestion but a real problem in UniDac components.
Will you improve soon TUnilareter by implementing an alert mechanism without using Synchronize?
An other UniDac specifcity is that everything is very thread critical. E.g. see viewtopic.php?f=28&t=34740&p=121147#p121147
Both specifities don't match and are imposed by UniDac what results in problems. So, we are not talking about a request to asuggestion but a real problem in UniDac components.
Will you improve soon TUnilareter by implementing an alert mechanism without using Synchronize?
Re: UniAlerter and threads
The specified behavior is not a bug, but TUniAlerter implementation specificity for multithreaded applications - this behavior is correct.
Changing the current TUniAlerter behavior will affect a lot of our users, who already use it, therefore we cannot change it.
If you want us to implement the alert mechanism in UniDAC without using the Synchronize method, please leave your suggestion at our UserVoice ( http://devart.uservoice.com/forums/1046 ... components ). If the suggestion gets enough votes, we will consider the possibility of its implementation.
Changing the current TUniAlerter behavior will affect a lot of our users, who already use it, therefore we cannot change it.
If you want us to implement the alert mechanism in UniDAC without using the Synchronize method, please leave your suggestion at our UserVoice ( http://devart.uservoice.com/forums/1046 ... components ). If the suggestion gets enough votes, we will consider the possibility of its implementation.
Re: UniAlerter and threads
By implementing a new property "MultiThreaded" you can easily avoid problems for other users who use already UniAlerter. By default the new property MultiThreaded is false, that means the event is called from the main application thread like it always did. When MultiThreaded is true, that means the event is called in the same thread as where the component is created. Such property is quite common to use components in multihtreaded applications.
1. From your documentation about TUniAlerter "Events are transaction-based" A transaction runs by a TUniConnection. The same TUniConnection that is used by a TUniAlerter.
2. In the documentation of TUniAlerter is nothing described about multithreading and information that the event is called from the main application thread.
Consequently, it's quite normal to expect the event is called from the same thread as where the component is created.
For these reasons, I don't agree if you mention it is not a bug.
Actually I'm looking for a solution in short term, not a discussion. Can you help us?
I've added a suggestion at UserVoice, but I'm affraid that don't help me further on short term.
1. From your documentation about TUniAlerter "Events are transaction-based" A transaction runs by a TUniConnection. The same TUniConnection that is used by a TUniAlerter.
2. In the documentation of TUniAlerter is nothing described about multithreading and information that the event is called from the main application thread.
Consequently, it's quite normal to expect the event is called from the same thread as where the component is created.
For these reasons, I don't agree if you mention it is not a bug.
Actually I'm looking for a solution in short term, not a discussion. Can you help us?
I've added a suggestion at UserVoice, but I'm affraid that don't help me further on short term.
Re: UniAlerter and threads
We added your suggestion about implementing the MultiThreaded option to our roadmap. But as none of our users, except you, was interested in this functionality, the priority will be low and we cannot name the exact terms of its implementation.