I just wanted to highlight the fact that ProDataSet are probably only there in the first place because of the .NET OpenClient.
I'm not sure. Part of its strategy - especially for updating data - has been available in the SmartDataObject of the ADM2 since V9.0. And the relational aspect was "prototyped" (poorly, o.k.) as the SmartBusinessObject in 9.1x. The ProDataset is the natural evolution of that added to the core of the language.
V9.0 was much earlier than .NET 1.0
The point: ABL is converging to .NET; take the next logical step and make it a .NET language with Progress added bonuses on top of it.
dlauzon wrote:The point: ABL is converging to .NET; take the next logical step and make it a .NET language with Progress added bonuses on top of it.
Or make a database driver to use Entity Framework against an OpenEdge DB
dlauzon schrieb:The point: ABL is converging to .NET; take the next logical step and make it a .NET language with Progress added bonuses on top of it.
(If there would be agreement on the sense:) Do you any other language that has quite that many keywords as the ABL that has succeeded that route?
Are you willing to wait (patiently) for 5 years for such a release and not seing much else being released in the meantime?
It is not converging to .NET. Yes, you can find some parallels here and there, but you can also find parallels to other languages and you can find lots of differences.
Are you really suggesting that we give up ABL access to the database and go completely SQL like .NET?
And, what does this have to do with my multi-threading thread? It isn't going to happen in any foreseeable future and I hope it doesn't happen in any unforeseen future. The whole point of this thread was to make a case that multi-threading is overdue for the ABL and that there are a number of ideas for possible solutions which don't seem as staggering as rewriting the whole AVM. Your proposal would get us nothing for many years while we waited for them to complete the work. Let's get back on track for proposals that will be useful in the next release or soon after.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
Alright, I'm giving you back your thread.
I certainly hope not.
Let's put it this way, Mary and Gus are to Progress what Charles Simonyi is to Windows programming or Erich Gamma is to design patterns.
Of course, Mary and Gus also happen to be two of the nicest people you will ever meet. Very down-to-earth, straight shooters. Both of them are completely willing to accept that they may have the wrong idea about something, but way more often than not, they don't.
Neither of them particularly like the idea of being worshipped - they're mature enough and humble enough to recognize that they are human, and thus fallible.
If either of them speak, it is a good idea to listen first. They generally know a lot better than most people do.
"He's a witch!!! He's a witch!!! Burn him!!! Burn him!!!"
VB 5 was able to make a connection to the AppServer in V9, 1998. So was Java.
In V10.0 .NET support was added and VB support was removed. WebServices support was also added.
Right now i am developing web application. It is just pilot project. And it uses async multithread algoritms to work with OpenEdge Database.
1. Appserver works in statefree-mode. It opens new thread with every request got from WSA.
2. I do not use any progress SESSION. There are only virtual sessions supported by context managment DB.
It works like this:
Client (flex) is totally multithread. It uses anync model to display data and uses async model while calling web services.
All you have to do is send async request and add EventListener for Result to display incoming data.
Request are sending to WSA. It operates in statefree mode and seeks for new thread to execute query.
Appserver does its work and returns record sets. WSA sends it in async mode to client. Client event trigger fires and displays data.
At user level it looks like this:
User opens large document with 3-5 tables within it.
Client sends paralellel request to wsa for Every Table and every Frame in document.
Client displays results when Triggers fires. I noticed that for small data sets (like document header) client displays data fast. And for large tables it takes some time.
File uploading/downloading works as background processes while comunicatiting with appserver's file systems. Client just displays how many chunks transfered by every process in background.
These processes do not stop any user activity.
ok this thread is now 3 years old...are there any news about multithreading in openedge?
By now it should really be a number one priority for progress to make it happen
Yes, there is news, but not necessarily the news one would prefer. Work is under way on the next generation AppServer which will be multi-threaded, but not in the sense that an individual session will be multi-threaded. Rather, it means that an agent is multi-threaded and can spawn new threads for new sessions instead of having to spawn new processes, thus lowering the overhead of starting a new session and of maintaining an existing session. Somewhat ironically, this will mean that one can shift from the current emphasis on statelessness to achieve scalability to statefulness, since keeping a session alive only means maintaining state on a thread, not tying up a whole session. I have asked about the use case of session calling session in order to provide a kind of multi-threading, but don't have a firm answer. I have also asked about multiple sessions calling the same session, i.e., to provide persistent services, but don't have an answer on that either.
But, this is not the multithreading for which I have argued. That still is in the category of "too hard".
If you want to discuss the next gen AppServer, we should probably start a new thread! :)
I don't use the AppServer so this isn't really any good news for me.
I am very disappointed from Progress, this should be a standard since years and there is no effort do so so.
Yes, it may be hard to implement it but it is not impossible so this is really no excuse...(espacially since every dev i speak to asks for this since many years)
...shame on you progress
To be fair, there is concern about the kind of trouble which people are likely to get themselves in. Multithreading is hard, not just to implement, but to do in such a way that people can reasonably create thread-safe code. There are some people, most visibly Greg Higgins, who for some years have been achieving a kind of multi-threading by having a Sonic service which makes asynchronous AppServer calls to handle each request allowing the Sonic service to return to responding to messages. I realize that this requires Sonic and AppServer and you may well be doing neither now. AppServer is something you should be looking at ... that you aren't suggests that you are still dealing with monolithic ABL clients which talk directly to the database ... not exactly modern architecture. While you may not feel a need for Sonic, there are some lightweight, open source implementations of messaging which you can use instead.