Multi-threading -- It's time

Completely agree! Moreover, I think that the right time came long time ago. In addition to your cases I can mention that one can't call .NET code from ABL if it uses multithreading.

On the other hand I'm afraid it's not a piece of cake for PSC to re-work their AVM for multithreading, that's why they are delaying its implementation.

Frankly, I think it's too late. Multi-threading is not just a nice to have anymore, and it hasn't been for a very long time. The fact that we do not have multithreading in the AppServer makes it completely unscalable.

When I start up an AppServer, I have to build caches of information that are available for subsequent calls so that the AppServer does not need to go to the database for every call. This is not optional - it's essential. In Glassfish or Tomcat (Java AppServers), I spin off a thread at startup to go and build those caches. There is no notion of an agent process with Glassfish or Tomcat - the agent is a thread. This means that each agent has access to a common cache and there is no processing associated with gaining access - it is all in-process. With OpenEdge, I have to build that cache **for each agent** which means that it significantly increases the amount of resources used by the AppServer.

Moreover, with Glassfish or Tomcat, an update to the cache is available to all agents. With OpenEdge I have to jump through hoops to make that possible.

I could go on an on. Collection implementations without multi-threading means that the user has to wait while a collection's underlying structures are cleaned up after the deletion of an item from the collection. Of course, we would not need to implenent collections ourselves if they had been implemented in the language for us in the first place.

I have a specific use case right now where I really need multi-threading. After a record is written to the database, I need to call a WebService. There is no need for this to happen inside the transaction, but it has to happen as a result of it. If I had multi-threading, I would create an object with the information that needs to go to the WebService, and put it in a queue to be processed, and then return control to the UI. In the background, a worker thread could pick up the object from the queue and make the WebService call for me and write the updates that come from it to the database. I can't do that. I now have to wait for the call to execute before control can return to the client.

Unfortunately I don't hold out much hope of this happening.

1) Retrofitting multi-threading to the AVM is going to be a big job;

2) The problems associated with Multi-Core make this job even more complicated than it used to be, and that is something from which Progress would have to shield OpenEdge developers;

3) The return on investment from Progress would not be significantly measurable.

The problem is that without it, I am better off writing large chunks of my code in Java/.NET and treating Progress as the back-end system responsible for maintaining my database an referential integrity.

When I start up an AppServer, I have to build caches of information that are available for subsequent calls so that the AppServer does not need to go to the database for every call. This is not optional - it's essential. In Glassfish or Tomcat (Java AppServers), I spin off a thread at startup to go and build those caches. There is no notion of an agent process with Glassfish or Tomcat - the agent is a thread. This means that each agent has access to a common cache and there is no processing associated with gaining access - it is all in-process. With OpenEdge, I have to build that cache **for each agent** which means that it significantly increases the amount of resources used by the AppServer.

On the plus side, presentations I've seen have detailed plans to implement a shared cache across multiple appservers as part of the "multi-tenant" db upgrade scheduled for release in v11.

On the minus side - v11 is still a ways away.

timk519 wrote:
When I start up an AppServer, I have to build caches of information that are available for subsequent calls so that the AppServer does not need to go to the database for every call. This is not optional - it's essential. In Glassfish or Tomcat (Java AppServers), I spin off a thread at startup to go and build those caches. There is no notion of an agent process with Glassfish or Tomcat - the agent is a thread. This means that each agent has access to a common cache and there is no processing associated with gaining access - it is all in-process. With OpenEdge, I have to build that cache **for each agent** which means that it significantly increases the amount of resources used by the AppServer.
On the plus side, presentations I've seen have detailed plans to implement a shared cache across multiple appservers as part of the "multi-tenant" db upgrade scheduled for release in v11.
On the minus side - v11 is still a ways away.

If this is implemented the way that it was being spoken about 6 years ago when we had all the problems with Dynamics' AppServer performance, it's a kludge. The idea was that the broker would hold a cache of data that it would share with each of the agents and that it would be made available to agents as they were activated. No matter how you cut it, this results in inter-process communication and it is going to be slow. Much slower than a cache that is available inside the same process that has thread synchronization in place to prevent deadlocks.

Multi-threading the AppServer is the right solution.

Of course it's dangerous to discuss features that are not yet released and I'm therefore not at liberty to say much other than, No, the current thinking is not to do an implementation along the lines you summize.

OK, so now we know one thing you are probably not going to do .... I don't suppose that you have any hints on what you might do?

Or, at least, do you recognize the problem and how important it is?

Actually I doubt that it is all that hard.  It certainly doesn't require a major rewrite of anything -- just the addition of a little syntactic sugar to the 4GL to allow coordination  of threads.  Then just instantiate multiple copies of the current AVM as threads within a session.  The first one could be the UI thread and all others would be "batch" threads (run as if -b were specified).   Technically it's not such a big deal.

Tom,

I don't agree with you on this one. This is definitely very, very hard for OpenEdge for a number of reasons.

1) Most of the core language is still in C and that means that the object nature really doesn't exist. Threading is hard enough to do in Java where everything is an object and all your garbage collection is taken care of for you. In C, threading is rocket-science.

2) Progress does its own memory allocation which is both a good thing and a bad thing. The problem is that it was not written to be multi-threaded so any work you do on multi-threading the AVM requires that the memory allocation be multi-threaded and carefully tested in a multi-threaded configuration. That's a very big job.

3) 2 applies to several other key resources, including database buffers, queries, etc. They all have to be multi-threaded if you plan to multi-thread the AVM.

4) Threading is one thing. Parallelism is another. Now that we have multi-core machines, the problems associated with threading are exponentially more difficult to handle because context switching is complex enough on a single core, but context switching across cores is extremely expensive and can actually degrade performance. Processor affinity is a very key concept to understand and it does not come for free in the OO languages. How much worse is that in C?

So multi-threading is not just syntactical sugar. This is a huge change to the way that the AVM works. I think it is probably a 3 year development effort alone, and there are language constructs that would need to be deprecated to support it. Don't underestimate how big this is. It's probably bigger than replacing the database engine.

I get why Progress has not done this. It's a much bigger development effort than the GUI stuff. The problem is that if they had set up a task force to do it back in the late 90's when the idea was originally gaining traction after the deployment of AppServer, it would be well-baked by now. The problem Progress faces now is just how much life does OpenEdge have left in it? 20 years ago I would choose Progress automatically if I was building a new application. There was no question about it. 10 years ago, Java was starting to show, but you could always argue that database and AppServer work with Java were much harder than with Progress. Today, business logic to database is the only place that OpenEdge really has an advantage, and then the problem you face is scalability of the AppServer.

Now if Progress would go back to viewing OpenEdge the way that it has always been successful - that is, as a data manipulation language and a great platform for business logic - the money would be invested in the right technologies that would make building the world's best business applications possible. It starts with the AppServer and database.

I wonder if there isn't a middle ground here.  Tom's concept is certain simple-minded multi-threading in that the threads might as well be in different sessions, but that alone would be a major leap forward.  I don't know that we need to share things like database buffer and such.  Each process could really be in its own memory space and the only communication would be through parameters and events.  Yes, there would need to be some glue in the middle because each thread is so agressively single-threaded so we would need structures for making sure that an event or return hung around until the session it was targetted at was in a proper state to recieve the action and that implies queuing, but I think this could be simpler than you outline.  It would have limitations, of course, but would still be a major leap forward.

I think you're right. I think there is a middle ground.

The other place this would need to be carefully thought out is in supporting multi-threading in the .NET GUI. Background threads in the CLR will need to communicate with background threads in the AVM. That is going to create some interesting language questions.

Of course, the new Task Parallel Library (TPL) in .NET 4.0 is going to add a whole new wrinkle when .NET 4.0 is eventually supported sometime in the future. This is one area where .NET has taken a big jump ahead of Java. TPL significantly reduces the complexity of multi-core parallel programming.

It starts with the 4GL.   The 4GL has always been the core reason why people use Progress.  Letting the 4GL stagnate has always been the root cause of the various ills suffered from time to time.  All else flows from the 4GL.  If the 4GL is healthy and robust then the rest of the ecosystem thrives.  If the 4GL is swept into a corner angst and unhappiness ensue.

As you and Thomas have recognized I am advocating a compromise approach to multi-threading.  I think that it is viable -- today's hardware is more than capable of supporting such an approach.  From the 4GL programmer's perspective it should not manifest as a major change -- it really should just be a little syntactic sugar.

While I'm at it...  each "thread" could, in truth, be a process.  It only needs to look like a thread, it doesn't have to actually be one.  That might even have some advantages (think of Chrome's solution of running browser tabs in their own process).  That would make it even easier for PSC.

The problem with treating it as a separate process is the same problem we face with AppServer - which is why I raised it. Sharing a memory store that is out of process is difficult and a performance penalty.

One of the things I want to be able to do is have parallel FOR EACH statements running that update a common temp-table for data extracts. Ideally, I would like these to run on separate cores so that I can have true parallel processing, not just multi-threading.

Microsoft has messed up a lot of stuff, but they have come up with an idea in .NET4.0 that I think we could really benefit from.

The following is directly lifted from a paper that MSDN has published that is available at the following blog: http://blogs.msdn.com/pfxteam/.

Parallel.ForEach

The Parallel class’s ForEach method is a multi-threaded implementation of a common loop construct in C#, the foreach loop. Recall that a foreach loop allows you to iterate over an enumerable data set represented using an IEnumerable. Parallel.ForEach is similar to a foreach loop in that it iterates over an enumerable data set, but unlike foreach, Parallel.ForEach uses multiple threads to evaluate different invocations of the loop body. As it turns out, these characteristics make Parallel.ForEach a broadly useful mechanism for data-parallel programming.

This kind of thing would need to run in separate threads.

The funny thing is that the AVM actually does spawn more than one thread. How else could it do asynchronous AppServer? So exposing that kind of functionality that way is possible. I think it should be possible to find more use cases for specific things like this. Sockets, for example, need to have limited multi-threading. So do queries, streams, webservice requests, and so on.

Matching a .NET thread to an ABL thread when it was .NET that spawned the thread, not ABL could be one of those non-trivial things you were alluding to!

While I believe in planning with a long term vision, this is one area where I would be happy for them to do *anything* to get the ball rolling.  I don't think we can solve the problem with truly separate sessions alone since they would then need to communicate and, without the communications glue, one would be stuck again with multi-node communication without multithreading, which I think doesn't work.

But, the idea of gluing together what amount to independent sessions, each running on a thread within a single process, and provided with some communications glue is something that I think would be a meaningful step in the right direction without being all that complicated.  One does need to handle queueing of events and returns in that glue, since the individual sessions can't, but I would think that was pretty standard stuff and something that the engine crew knows inside out.  And, it doesn't take a major language change since it is really just a local version of an asych AppServer run.  In fact, I think I could handle the idea that each session was sufficiently independent as to have its own DB connection.

I do think we need to recognize that multithreading addresses more than  one need.  From a quick glance, the purpose of the TPL offering is true  parallelism, i.e., taking a big compute problem and breaking it down  into multiple parts so that the computation can complete faster since  each part is being run on a serparate processor or core.  While there  are some problems that might fit in that category, I don't know that it is particularly typical, especially if one separates the class of problems where the data to be processed reside in the DB, so retrieving the data is the actual primary bottleneck.

But, these problems are somewhat different than the problems which I am thinking about in needing multi-threading.  They don't so much deal with compute intensive requirements as they do the need for asynchronous execution.  E.g., the problem with the lack of multi-threading in socket handling isn't the huge amount of processing that is needed to deal with a received message, it is the fact that one needs to keep listening while that processing goes on, however long and intensive it might be.  Yes, there are times where that processing might be a big deal, but even when it isn't, we have a problem because a single-threaded process can't be both listening and doing at the same time.  Likewise with UI requirements.  They may not be compute intensive at all ... in fact, a common requirement is for a thread to be getting the next batch of data in the background while the user continues to interact with the screen in the foreground.  That background task actually spends most of its time doing nothing because it is waiting for the disk IO on the remote system and the network transfer of the data.  But, a single threaded session can't be simultaneously waiting for the network response and paying attention to the user.

It is conceivable that we could accomplish some goals if we had real interrupts ... by which I mean that the program could be working on a task and there was the ability to interrupt that task, save the current state, handle some other event which had occurred, and then resume the original task.  But, that requires queueing of events in order to wait for appropriate save points or to be able to nest interrupts multiple levels deep.  This actually sounds harder than the proposed "simple" version of multi-threading and less flexible.

So, what would we need to implement this proposal?  We need a new "glue" component which goes between the threads (or sessions) such that one thread can run a program or internal procedure in another thread and pass parameters.  If we are dealing with separate sessions, then we have the problem of passing things like temp-tables across a thread boundary ... which we can already do with AppServer, but one would like to avoid that much overhead.  If we are dealing with threads, not processes, it seems like it would be reasonable to have some common data area.  While that sounds like a good way to shoot oneself in the foot, I don't know that it needs to be a problem.  If thread 1 defines a variable X, then the value of X could live in a shared data area without conflict as long as there is some kind of lock or broker so that only one process is modifying the data area at one time.  Make them separate data areas and you don't need that, but it does seem like it would be desirable to have a keyword which would allow sharing of data structures like temp-tables across threads.  That is definitely going to require a bit of coordinating, but doesn't seem that hard.

Then, I suppose we need a queing feature so that multiple threads can push events to other threads and there is a way for the receiving thread to process those in order.

What else?

>>  each "thread" could, in truth, be a process

Well, Tom, we can run a separate process from ABL code right now. Actually we can even organize interprocess communication using either file system or sockets however that's not multithreding. Anyway I agree I like an idea to have some syntactic sugar to do that easier than now. Moreover, I'm starting thinking if new language constructs allow me easily to run a well-incapsulated procedure without its rewriting, I'll be happy.

I am wondering if it is not safe to switch to other env for new developments. I would not embrace all object stuff from .Net because it is very difficult to successfully design ua large scale data oriented software with it. But I think datasets oriented .net software is becoming worthwile, along with the speed of SQL server.

Spawning a process is not really acceptible because the start up performance is punishing.  Spawning a thread is a very lightweight action.  Communication via the DB and filesystem are not acceptable.  Just too slow and requires polling, not event driven.  I would accept separate processes if we could spawn them to create a pool and then have some high quality communication between them, although I have concerns about the load on the processor if we suddenly have four or five times as many processes on the system.  But, we need that high quality interprocess communication for any scheme.  And, that communication has to provide the event queueing and such that we can't do for ourselves.

What if the process is just a "worker" process spawned once (not a hundred times) and used across the primary session when needed?

E.g.

DEFINE VARIABLE hWorkerSession AS HANDLE NO-UNDO.
CREATE SESSION hWorkerSession CLONE THIS-SESSION. /* CLONE = use all the same parameters as the current session; there would be a way to specify completely different session settings */

RUN MyPath\MyProcedure.p ON hWorkerSession ASYNCHRONOUS (someParameter).
/* or in some procedure far from the spawned session creation: */
RUN MyPath\MyProcedure.p ON SESSION:FIRST-SPAWNED-SESSION ASYNCHRONOUS (someParameter).

/* or even */
RUN MyPath\MyProcedure.p ON SESSION:FIRST-AVAILABLE-SPAWNED-SESSION ASYNCHRONOUS (someParameter).

The CREATE SESSION could be wise enough to spawn the session in a different core (if one exists) than the primary session.

By the way, for potential voters, the enhancement request number for threading is #3332.

One of the things that I have heard repeatedly is that there are a lack of real world use cases where threading is absolutely essential. It's often very hard to articulate those use cases without good examples, but I am working on something right now where multi-threading is really the only viable solution to the problem.

In a posting this week on my blog at http://www.thesoftwaregorilla.com/2010/04/exchange-web-services-subscriptions-and-notifications/, I described the way that Microsoft Exchange subscriptions work. The diagram in that posting (http://www.thesoftwaregorilla.com/wp-content/uploads/2010/04/Exchange-Web-Service-Subscriptions.jpg) shows the flow that I am working on. There are two places where multi-threading is not just nice to have, but essential for scalability.

Both of the examples I am using are illustrative of a common pattern of enterprise application integration.

The First Example - the Exchange Acknowledgment

The first is in the way that my Java HTTP Servlet deals with the messages from Exchange. Exchange sends a notification to the servlet (2.1 in the diagram) that indicates that an item in the Exchange store has changed. The servlet has to respond for Exchange to maintain the subscription, and in responding Exchange knows to go on to the the next message in the queue. So I need to send the ACK back to Exchange in the HTTP response (2.2 in the diagram).

The notification that I received from Exchange only tells me that the item has changed; there are no details about the item, so the Servlet calls Exchange (2.3) to ask for the information about the item. There is no need for Exchange to wait for 2.3 to happen before 2.2 happens. Exchange should send me the next notification as soon as possible. But I do need to make sure that 2.3 happens.

So the way it works is that 2.3 is running as separate background threads. When I get the notification in 2.1, I put it into a queue and ACK it (2.2) so that that Exchange is free to send me the next message.  The background thread picks up items in the queue and persists them so they are not lost (I'm probably going to do this on the same thread as the ACK so that the ACK is only returned once the notification is persisted - guaranteed message delivery). It then notifies another background thread (item retriever) that reads the persistent store, retrieves the item from Exchange, and persists that result with the original notification. Exchange can, in the meantime, have sent more messages because I already responded. So as a result, my listener is not a bottleneck.

Another thread is responsible for listening to messages from the item retriever. When it receives a notification that we have all the information related to a message, this thread makes a call to the OpenEdge AppServer (2.4) with the information about the item.

The question is, "Could this have been written synchronously?" The answer is, Yes, but the performance would suck and you make the Exchange Server wait until the message has gone all the way to the ABL before you can respond to Exchange. In the meantime, Exchange thinks your listener has died and retries.

This code is so critical, that there is no way that I can write it in the ABL. I have to write this code in Java because the ABL just can't do this.

The Second Example - the ABL call

Once the call in 2.4 takes place, we are inside an ABL AppServer agent. There is a bunch of stuff that has to happen now:

1) The item that I have received needs to be validated to determine if I need to store it.

2) I need to store it to the database.

3) I need to notify the application that there is an item change that it cares about.

4) The application needs to deal with the item change as it sees fit.

Again, storing the information to the database is the only thing that need to happen before I should release the Java thread in the servlet that is waiting for the call to happen. But the OpenEdge AVM session is the only place where I can notify the application that this information has come in, and I have no way of knowing how long the application is going to take to process this item. So instead, I hold on to the Java thread that called me until that processing is complete.

Ideally I should be able to accept the item, persist it, notify a background thread, and acknowledge receipt. The background thread should then notify the application and its processing should be something that the Java service does not have to wait for.

Lest you think this example is contrived

I was working at a Progress customer who shall remain anonymous (we'll call it ABC) a few years ago where this exact issue caused the customer to lose support from one of its vendors (XYZ). XYZ was providing the ABC regular updates on things that were going on with ABC's customers. ABC needed to react to these events in real time so that the customer satisfaction level could be high on a new product stream. ABC also needed to do quite a lot of processing when it received the event from XYZ. Several different systems were involved in the process.

ABC decided to process the entire event within one OpenEdge AppServer call and the result was that XYZ was waiting as long as 3 minutes for the ACK to come back. Ultimately, XYZ downgraded ABC's usage of their services and refused to meet a 30 second SLA because ABC could not release its resources in time.

Now there are definitely things that were wrong with ABC's architecture. ABC could have built this architecture with multiple processes, and polled database tables and all kinds of stuff to work around the lack of multi-threading. But right there is the issue. It's a work-around.

Fine, but we need the "glue" to enable those threads to talk to each other ... queuing of events and the like.

Rather than thinking your example contrived, what I can't figure out is why the use case here isn't abundantly obvious.  Any time there is a service in which some time is required to fulfill a request, one would like the service to receive a request, spawn a thread to fulfill the request (or pass the request to an existing thread), and go back to being ready to receive the next request.  Especially if the time required for a response is highly variable.  Especially if the requestor needs an acknowledgment that the request has been received.  Examples of wanting this are abundant.

tamhas schrieb:
Rather than thinking your example contrived, what I can't figure out is why the use case here isn't abundantly obvious.  Any time there is a service in which some time is required to fulfill a request, one would like the service to receive a request, spawn a thread to fulfill the request (or pass the request to an existing thread), and go back to being ready to receive the next request.  Especially if the time required for a response is highly variable.  Especially if the requestor needs an acknowledgment that the request has been received.  Examples of wanting this are abundant.

Excuse my stupidity. Either I'm not getting your point or there's something missing in that description: But isn't what you've described here exactly the way the AppServer is working?

Rather than thinking your example contrived, what I can't figure out

is why the use case here isn't abundantly obvious.

> Any time there is a service in which some time is required to

fulfill a request, one would like the service to receive a

> request, spawn a thread to fulfill the request (or pass the request

to an existing thread), and go back to being ready to

> receive the next request.

The contrived part of the argument is when product management repeatedly

asserts the need for a use case.

Let me just clarify something about my last post. The reason I said "Lest you think this example is contrived" is that I am very aware that there are architectural ways to work around the Exchange issues.

Certainly, having a good MOM in the mix with an ESB on top of it can significantly mitigate the problem and probably do away with several of the issues. Of course, you are likely to get into a religious war around the issue of using middleware for business logic, but if you accept that is not a problem, you could orchestrate the service calls properly in the middleware.

The issue in the ABC case was that middleware really would not have solved anything. The compensating transaction issue would have been a nightmare. Even in the ABL Acknowledgement case, this is a messy issue to resolve.

Actually, AppServer is another place where we really need multi-threading for exactly the same reasons.  It just isn't efficient to try to package everything into a single .p with the life of a single call.  Works great for some things, but not for all by any means and there is lots of things we can't do with it at all.

Actually, AppServer is another place where we really need multi-threading for exactly the same reasons.  It just isn't efficient to try to package everything into a single .p with the life of a single call.  Works great for some things, but not for all by any means and there is lots of things we can't do with it at all.

I'm pretty sure that product management will need more details than that. The previous reply (the one I did comment on) did sound like a perfect fit for AppServer to me - and still does.

No, Mike. I don't think what we are talking about is the same as today. Today, when you call the AppSerber, no matter who the client is, you have to wait for it to finish processing before you receive an acknowledgement. We're talking about being able to spawn a thread and then return.

There are the small matters of overhead and latency. And not being able

to pass objects across app server boundaries.

The first two could be resolved by making it possible for app server

sessions to be a thread within the 4gl session -- which might even be a

clever bit of "syntactic sugar" for exposing multi-threading

capabilities in the 4gl The last one, is a bit more daunting.

Meaning that you have been happy with a dozen async requests hanging out there and how that works?

No, Mike. I don't think what we are talking about is the same as today. Today, when you call the AppSerber, no matter who the client is, you have to wait for it to finish processing before you receive an acknowledgement. We're talking about being able to spawn a thread and then return.

Bruce that's clear to me from your use case - because it looks at it from the clients perspective. Thomas' use case is from the AppServer's perspective serving a series of requests. That's a different requirement. Even when related.

Meaning that you have been happy with a dozen async requests hanging out there and how that works?

Not being happy with it or not seeing it as a critical platform limitation are two pair of shoes.

That's easy for you to say!

AppServer is still stuck back in client-server model.  Everybody else has the technology to deploy clouds and layers of services -- pool them an make them stateless when that is appropriate or provide consistent control points when that is appropriate.    We're forced into a one size fits all approach in which statelessness is the only game in town.  We can get some of the architecture we would like with a bus, but again we have the problem of building services which can scale and yet provide a control point.  E.g., 15 years ago one of the ideas which I thought was interesting in the Forte world was the idea that one could make a service the source for some rarely changing data, have each client that needed that data get it from that source and cache it locally, but then also register with the service for change notification.   In typical operation, there was no change and the client made a one time fetch of the data, but if the data did change, the source sends out a notice, either providing the change or signalling that the data needs to be refreshed.  This is a great way to handle fairly static data with minimum overhead.

How would you propose doing that with AppServer?

How would you propose doing that with AppServer?

The key point of that requirement is the (missing) ability of the AppServer to notify clients without MOM?

Are you considering that it would be a good thing when 1000 client have requests to threads on the AppServer open just to get a response when that rather static data eventually changes?

I doubt that. The solution to that requirement would be a MOM, let that be Sonic, FUSE or anything else. Or even something in the AppServer protocol - like the ability to use the AppServer connection in reverse order. Which would also help to get a status response during long running requests (sync or async nature).

No, the key requirement there is to have a single service responsible for the data.  Notification could happen through a different channel, I suppose.

No, the key requirement there is to have a single service responsible for the data. Notification could happen through a different channel, I

Well that wasn't clear from your previous post. But why does this single service instance needs to be a thread and not a batch client listening to a Sonic queue?

As described, I was referring only to the degenerate case.  Yes, you can solve that problem with an ESB.  But, now make the data not quite so static. Let's provide for changes to be happening and the service needing to keep tranck of who's interested in what data and letting them know about changes.  I.e., multiple processes/threads making changes, but a shared registry of who is interested in what data.

Frankly, I'm surprised that you aren't in here arguing for multithreading, Mike, if only for the UI.  How are you ever going to get the ABL part of an ABL/.NET client to really handle everything on the .NET side unless the ABL side has multiple threads too?

Well hang on, Thomas. I don't think Mike is against the case for multi-threading. He's making a really good point about it, and it's the same point I've heard out of Bedford on more than one occasion:

It is not true to throw multi-threading in as the solution to every problem. Heck... thread pools can significantly degrade the performance of an application. Mike is trying to make sure we focus the use cases as valid use cases for multi-threading, and a service-oriented architecture approach actually argues against multi-threading. The threading is handled by the SOA infrastructure, so the end point is really just performing a single task. Thus the AVM is receiving a single request.

Of course, the problem is that the time it takes to process that request may require spawning a separate thread to do non-task-related work.

Your example of the static data is one that I am working with right now at my full-time job. We have a property data master that has to notify interested systems each time the zip code or street name for a property changes. The property data master is the cache for all properties in the United States. Any systems that reference those addresses, such as billing, need to be updated when the address is modified.

There is no two-ways about this - it is a SOA issue. Not a threading issue.

Frankly, I'm surprised that you aren't in here arguing for multithreading, Mike, if only for the UI.  How are you ever going to get the ABL part of an ABL/.NET client to really handle everything on the .NET side unless the ABL side has multiple threads too?

Please let me know where I was that unclear! I'm not against multi-threading (even when it's not that high on my priorities list). I'm just not convinced that the use cases here are real good use cases for multiple threads.It sounds mostly like a SOA/communication topic to me and should be solved as a SOA/communication topic. From my understanding the pure availbility of threads in the language won't for instance solve the inter-process communication between AppServer and multiple clients and registration on topics. There we are back to the MOM.

And for the UI - with very few exceptions - it has never been a real show stopper. I'm working on a project (POS implementation) where some hardware interfaces seem to require multi threading. That's a completely different requirement. In many other cases it's easy enough (with good enough understanding of the AppServer) to work around certain issues with using async calls. The UI doesn't care if it's talking to different AppServer processes or threads - as long as all have access to the same context.

I'm hardly suggesting that multi-threading is a universal answer to everything.  And, yes, I'm a big fan of ESBs too.  But, a service is a lot like a socket server ... what one wants is a listener paying attention to the messages which can then spin off handling that message into another thread so that it can get back promptly to listening.  Yes, there are some cases where one could accomplish that thread by spinning it off to an AppServer, but only if an entirely separate context was OK, i.e., no shared context or need for dialog, and only if the performance hit of a network round trip was sensible.  If there is shared context, the only way I get that on the AppServer is to resort to the database ... another performance hit.  If the service is one involving a lot of little tasks, then I am paying a lot of overhead to send the work request off to an AppServer.

There are some conspicuous cases like a multi-client socket server that we just plain can't do without multi-threading and hope for them to work reliably.

There is another broad group of problems where some kind of work around exists, but with a compromise, often in performance.  One just can't go out to the bus or across the network all the time just to run something in a different process.  This group includes some cases that become no can do because they won't scale.

And there is another group where one just has to lower standards.  One can get by.

But, why should we?  Why should we have to resort to writing stuff in other languages because we can't get the job done in ABL?  Why should we be accepting less performance or less capabilities in order to write in ABL?  It's 2010!

.NET 4 with the Dynamic Language Runtime is supposed to "enables language developers to more easily  create dynamic languages for the .NET platform" meaning that it can use any .NET class and be called by .NET classes. As a sample, Microsoft already re-implemented Python (as IronPython) and Ruby (as IronRuby).  Maybe what we need is IronABL: always benefit from the advances in the programming language world (so that we are not left 10 years behind on subjects such as threading) and get Business Oriented language bonuses from Progress.

Going elsewhere is always an option, but not one that PSC would like us to make.  With modern MDA translation, one could even get a productivity gain by going elsewhere.  But, I'd rather bring that productivity to ABL.

> I'd rather bring that productivity to ABL.

That's exactly what I was suggesting.  Why would Progress have to re-invent the wheel?  Make ABL a language compiled to .NET and you're future proof for all that will be coming out from that platform and you can focus on adding value specific to your niche.

It's as when programs passed from:

A- executing their own binary code that talked directly to the hardware

to

B- call operating system functionalities

In the B scenario, you can benefit from all the improvements to the OS and don't have to bother about adapting to any new hardware that might come out.

We can have the same kind of benefits if ABL itself migrates to .NET so that .NET productivity is available in ABL, starting with or including multi-threading.

What a horrible idea.  If ABL were going to be made into anything, it should be made into something that compiles into a language which is available across a lot of platforms.  I don't think you appreciate what kinds of monster programs would result from compiling ABL into .NET and what incredibly poor .NET code 99.9% of them would be.

There are already tools for translating ABL into Java and .NET.  The result is not pretty.

What a horrible idea. If ABL were going to be made into anything,

it should be made into something that compiles into a language which

is available across a lot of platforms. I

And what should that be - besides Java? I count you responsible for my

nightmares tonight...

Don't worry Mike... You don't need to lose any sleep. It's not going to happen.

There is not enough value in compiling ABL to an intermediate language.

First off, just compiling it does not give you multi-threading.

Second, language constructs do not map well - Just ask the guys who wrote the abstract syntax tree for OE Architect.

Third, the issue is not solved by moving to Java - you still have to deal with UI.

Finally, the real value of the ABL lies in the database interaction. Rebuilding that in any IL is not going to be worth the investment, especially as both Java and .NET have their own mechanisms for database interaction.

ABL already can't follow with the new platforms coming out, where .NET is (e.g. ABL support for Linux is limited to one flavour and I don't see any ABL on WindowsMobile or any cell phone / PDA system - being more and more used in businesses).

The way it's heading, ABL is going to be a server-side only language, something like a "stored procedure" language.

I don't think that compile into another language is a good idea regardless of the language.  All that suceeds in doing is creating a mess from the impedence map in the way that ABL and that language handle problems.   Moreover, doing so would in itself add no capabilities to ABL.

> Moreover, doing so would in itself add no capabilities to ABL.

With the Dynamic Language Runtime of .NET 4, it does.  IronPython and IronRuby can now use .NET objets.

"IronPython is an open-source implementation of the Python     programming language which is tightly integrated with the     .NET Framework. IronPython can use the .NET Framework and     Python libraries, and other .NET languages can use     Python code just as easily.   " (http://ironpython.net/)

What's wrong with ABL being server-side?  We've had OpenClient since 1998.  Frankly, I would rather have seen the effort that was put into ABL GUI for .NET invested in better ways of working with OpenClient and WUI clients.

And, there is a million miles between server-side and stored procedure.  Any good modern system has the bulk of the application on servers with a thin UI layer being the only thing not on the server.

Imagine... ABL compiled code could be called directly from another .NET compatible language...  I could program something in ABL and sell it as a library to anyone being .NETabled.

dlauzon wrote:
Imagine... ABL compiled code could be called directly from another .NET compatible language...  I could program something in ABL and sell it as a library to anyone being .NETabled.

Why would you want to do that? I'm not being facetious asking. I really want to understand why you think this would be useful. Can you give an example of the kind of library you would build?

And, what ABL syntax are you going to use to access that capability?

And, why exactly would you do that?  Let's see, I could use .NET tools to produce .NET code and make the best possible component because I have direct and complete control over all .NET features or I could write in ABL, not be able to access many .NET features because I had no syntax for doing so and the things I could access would come through mangled because of the different object models between the two languages.  Which seems like a better choice to you?

I could build bridges from other systems to Progress systems without having to go through the AppServer (in particular when the other system is already on the server side...) and without having to code in some other languages.

another example: we have a mother company using another system.  You can forget about them investing any time and money to pack their parameters in XML from their language to send that through ESB, or to embed in their system some Progress .dll to use OpenClient for direct AppServer invocation.  If I give them an object they can call easily from their language, we might have a chance and everybody wins.

How about something like "NEW System.Threading.Thread(param)"?

ABL language deals well with OpenEdge DB data for the business world.

Of course getting rid of ABL completely as you suggested would be an option, but then there would be 20 years of development that would be thrown down the drain and massive investments would have to be done in new systems and licenses.

Point being that there is no existing syntax and, if one is going to do the work to create the syntax and figure out how the interactions will work, it is a lot less effort to do that within the context of the AVM than it is to compile into .NET, especially given the many differences in the way that ABL and .NET "see the world".

The syntax is already existing.

ABL already had to adjust to the way that .NET "sees the world" (generic object orientation, array parameters, abstract classes, structured error handling, structured events, generics, ... datasets!, ...).

Concerning world visions, the gap is not as wide as it was 8 years ago and I see that it's rather ABL adopting the .NET point of view.

Well, that investment of 20 years of modifying the application to suit the business is the real powerful reason for not switching to another purchased package.  There are some people ... mostly those who have had an "unpleasant" license conflict with PSC ... who have or are translating their existing ABL code into Java or .NET.  This is not cheap, but certainly cheaper than building a new application from scratch.  And, often the goal is to get on a platform where there are no licenses or where the only license is the DB, possibly one they are already using for other purposes.  But, the code which is produced by this process is a horror ... just imagine Java or .NET written by someone which a completely procedural mentality and no understanding of OO who was sloppy and inconsitent to boot and had only the most minimal understanding of best practice in the language in which he was writing.  I.e., one needs to spend as much again on refactoring as one spent on translation just to get something that one remotely wants to live with.  And, even if you do all of that, you end up with something that takes 3 or 4 times longer to make any future change that it did in the ABL environment.  But, you do get more respondents to your ad for a programmer ... whether or not any of them are any good.

If I give them an object they can call easily from their language,

we might have a chance and everybody wins.

That's exactly what OpenClient does. They should not worry about the

implementation when the Interface is right.

The syntax is already existing.

We have syntax in ABL that doesn't do anything?  If we had it and it worked, we would already have multi-threading and the response to this thread would have been RTFM.

I see that it's rather ABL adopting the .NET point of view.

Horrible thought.  I don't find .NET a particular fine example of OO thinking.

We have code that uses the OpenClient library and I can tell that it's not a one liner to call something like GetClientInfo()

Horrible thought.  I don't find .NET a particular fine example of OO  thinking.

Has ABL OO thinking brought anything new?

The syntax is already existing.

We have syntax in ABL that doesn't do anything? If we had it and it worked, we would already have multi-threading and the response to this thread would have been RTFM.

Not exactly -- but sure, there is plenty of syntax that could magically

become the gateway to multi-threading if it existed.

RUN ... ON ... for instance would work quite nicely. All we would need

is some sort of CREATE THREAD or NEW THREAD, a little magic fairy dust

for synchronization here and there (which might not even require new

syntax) and presto! Yup, there's some work behind the scenes but us 4GL

programmers shouldn't really need to worry that 50 new keywords will be

added to the language.

--

Tom Bascom

+1 603 396 4886

tom@greenfieldtech.com

http://greenfieldtech.com

We have code that uses the OpenClient library and I can tell that it's not a one liner to call something like GetClientInfo()

You certainly could create a simple wrapper - which would always be required when you need to implement custom Interfaces.

And in what language would that wrapper be?

OO language features in ABL are still playing catch up.  It would be pretty surprsing if they managed to innovate something actually new, don't you think?

On the whole, I am pretty happy with the design choices they made  in what they have implemented thus far and my wish list for important features not yet implemented is a lot shorter than it was a few years ago.

However, I can't be that complementary about the uses to which those features have been put, i.e. the actual models of OO code.

And in what language would that wrapper be?

It's not relevant - because the wrapper doesn't do a lot. I personally would choose C#.

Could I choose ABL?

In the language of the client.

OO language features in ABL are still playing catch up

So we pretty much agree that ABL is not innovating anything new to OO but is rather adopting OO concepts that are familiar to .NET (i.e. adopting .NET worldview instead of going further in it's own inovative ABL worldview).

Could I choose ABL?

No. But you shouldn't worry. It's just a wrapper, nothing relevant.

I'd rather code in a language in which I am thoroughly familiar than to take a chance to build something that looks like the horrible stuff that Thomas talked about: code that looks like it was coded by someone who doesn't have "the most minimal understanding of best practice in the language in which  he was writing".

Language syntax to merely do the run is not a big stretch on current syntax, to be sure, but those "small additions" for the run, cross thread interaction, etc. have to be parsed into something specific before they are useful.  It isn't as if one just magically would pick up all of .NET's multithreading features without making that connection.

As I said, I don't find .NET to be a particularly good reference point for OOP.  The influence of .NET on ABL is unfortunate in some ways although not surprising because of the ABL GUI for .NET work.  I don't feel that this is adopting .NET worldview since the language people seem to be more thinking in terms of what makes good OO, regardless of language.  Naturally, their choices are likely to have a somewhat different flavor than similar features in other languages, e.g., the integration of the new error handling with existing error handling and a block oriented versus TRY {}.

OOP is a mature field of study.  It would be stupid to do anything other that to learn from that history and background.  The innovation comes in doing a good job and making the right choices.  How innovative, after all, is FOR EACH?  It is the way that the whole works together that is the source of the quality.

Fine, you stick to ABL.  Have someone else write the wrapper. Do you think it sensible that you should be able to write an ABL wrapper for a .NET component to be used by .NET code?  Lovely notion, perhaps, but just not the current state of the art.

No doubt that is true. But it doesn't mean that we poor, simple 4gl

programmers need to clutter up our lives with new syntax.

PSC has historically been very good at packaging impressive new

functionality into relatively little new syntax. I think they can do it

again here -- there may be some "heavy lifting" under the covers but

there is no obvious reason why it should be exposed to us.

You got it, the point was that if I have an ABL wrapper, I don't even need to wrap OpenClient invocations since I'm already in ABL.

The .NET framework already has a (growing) number of languages (e.g. C# and VB.NET) that tap in the same pool of "basic" features (although they have completely different syntax e.g. C# and VB.NET) and are interoperable and I don't see why this is a problem or not state of the art.

It's as lovely as being able to build an .exe from many languages and be able to call that .exe from many other languages because they all can deal with .exe.

The .NET framework already has a (growing) number of languages (e.g. C# and VB.NET) that tap in the same pool of "basic" features (although they have completely different syntax e.g. C# and VB.NET) and are interoperable and I don't see why this is a problem or not state of the art.

Are you suggesting that OpenEdge should have two ABL implementations? One on .NET and the existing one? Or are you suggesting that Progress should give up on some of it's supported platforms (Linux, HP, AIX, ...)? Or choose to support ABL on Mono for those platforms?

As they whish.  If  ABL is .NET compatible, it should run on Mono as well as other .NET languages like VB.NET or C#.

Agreed that one doesn't need a flood of new keywords.  Sprinkling ASYNC here and there might do a lot.  But, the implication of those small changes are non-trivial.

You might notice a certain communality of vendor in those languages.  It is one thing to design a common CLR and two languages which will both use the same CLR and quite a different thing to take a completely unrelated language and compile it to that base.  Likewise, there are specialized languages which compile into Java and thus can run on the JVM, but again, Java and the JVM were pre-existing and the specialized languages were designed to that base.  ABL wasn't.

In fact, my first 4GL, of my own creation in 1979, was like that ... an existing language and compiler and a higher level language built on top.

sponsored by Microsoft

?????

Do you have a link to a news article as a reference to that? AFAIK they have just agreed with Novell that they will not do anything because of their potentially violated patents.

I though I read it somewhere, but since I can't remember where, I'll remove that part of the comment.

Python and Ruby weren't developed to run on .NET.

Of course, the thing is new to .NET 4 that was released a couple of days ago, so you might find a comunality also on the vendors of IronRuby and IronPython.

I though I read it somewhere, but since I can't remember where, I'll remove that part of the comment.

But for Progress and most VARs that would be the critical point. No way to invest in Mono when there is a risk that it can't keep up with MS .NET

The list of platforms is critical for many installatuions.

"Microsoft released the source code of .NET's new Dynamic  Language Runtime (DLR)—a critical component of Silverlight—under a  highly-permissive open-source license"

(http://arstechnica.com/microsoft/news/2007/05/mono-developers-to-bring-silverlight-to-linux.ars)

"That changed in January, when the first version of the Moonlight project  — a collaboration between the Novell-sponsored Mono project and  Microsoft, begun in 2007 — was released, providing Linux users with Open  Source Silverlight support. Also included, provided that Moonlight has  been obtained via Novell and meets certain other conditions, is a  license to Microsoft's free but closed-source Media Pack, containing  codecs needed to decode audio and video streams."

(http://ostatic.com/blog/microsoft-brings-silverlight-2-to-linux)

I think Wikipedia is not up-to-date.

Soooo, PSC is supposed to bet the farm on an open source release for Linux and hope that they can port this code to all of the platforms PSC currently supports????

"That changed in January, when the first version of the Moonlight project — a collaboration between the Novell-sponsored Mono project and Microsoft, begun in 2007 — was released, providing Linux users with Open Source Silverlight support. Also included, provided that Moonlight has been obtained via Novell and meets certain other conditions, is a license to Microsoft's free but closed-source Media Pack, containing codecs needed to decode audio and video streams."

(http://ostatic.com/blog/microsoft-brings-silverlight-2-to-linux)

I see nothing in the article that suggests that Microsoft "sponsors" Mono. I see it similar to the first commenter: Microsofts support is mainly not to sue the Mono team.

Furthermore the article seems to be restricted the Silverlight/Moonlight which is just a subset of .NET

MS sponsorship of Mono would have caused more noise...

Microsoft's "support" for Mono is a little more than not threatening to sue them. The reason I say that is that I have been in meetings at a corporate level with Microsoft over the last few weeks in which their representatives, speaking on behalf of the company, spoke about being able to run their products on Mono. Now that does not mean that they support it, but it does mean that they acknowledge it as a platform upon which to run their code, especially if they are suggesting that at a corporate level.

I am not surprised at the fact that Microsoft "supports" this. They regularly get hammered by large corporations on the fact that their products do not run on Unix. So they are facing increasing pressure in that area and Mono represents the first real success that they have seen in this space.

Moreover, and this is really worrying, Microsoft sees the Oracle acquisition of Sun as a serious threat to the future of Java and MySQL, and therefore a great opportunity for them.

Having said all of that, I would not bet the farm on Mono. Microsoft has a history of owning the technologies that are available and if it ever became a commercial product, Microsoft is very likely to own its own version of it that would require licensing, and it would kill the Mono project in the process.

I guess what I am saying is that Microsoft is watching Mono very carefully with an eye on subsuming it.

I.e., MS pays attention to Mono because it has to, not because it actually has any inherent interest in supporting  a platform other than Windows.

Were it to happen in some distant future that Mono became matrue enough and supported enough that it could be considered a reliable offering on every platform that PSC supported, then it could consider this proposal to compile ABL to .NET.  But, not only do I have considerable doubt that this future will occur, one has to ask why this would be an interesting avenue for PSC.  If it is going to do such fundemental and drastic work as to abandon the AVM for the CLR, there are many other alternatives which would be worth considering.  Compiling to native executables is regularly proposed, for example, but PSC has stuck with the AVM and p-code ..  a decision which seems reinforced by other technologies like Java which are doing something similar.  PSC could make vast enhancements to the existing AVM for a tiny fraction of what it would cost to covert to using the CLR.

Let me be clear: I do not for a second think that Progress should generate MSIL or JIL from ABL code. Not at all. As others have pointed out, there is no way that it adds any value to Progress at all.

All I was saying with my last post is that Microsoft is allowing Mono to germinate and grow as long as it is expedient for Microsoft to do so, and they are even encouraging its use. It is probably even likely that Microsoft is tossing money into the Mono project and allowing its developers to collaborate with the Mono development team. As to its future, if it has one, Microsoft probably has every intention of ultimately owning the technology.

I think we are on the same page.

The value would be in having access to .NET features from now on.

About betting the farm on one thing, I think that it already occured with GUI for .NET, although some might not like it.

I have not seen much promises about upgrading the UI for other platforms than Windows and I don't think that PSC have the ressources to follow the speed in UI advancements, neither do they have the ressources to follow the speed in language advancements, that's why they could benefit from being .NET compatible and just adding value over the .NET offer at each point in time, making ABL the best language to deal with business data in particular with an OpenEdge DB.

Infragistics uses this approach: .NET is there and already offers a bunch of UI controls, but they found a way to offer more than the standard offer so that we can build more powerful UIs with more intuitive constructs.

And on what PSC supported platform does OE Architect run?

Even the ABL language itself have not evolved a lot in regards to DB querying in comparison to all the efforts that PSC has put into SQL, and I don't see any hope that they will make the advancements (e.g. table statistics with automatic query optimization) available to ABL.

ABL GUI for .NET is really only interesting to people who are interested in fat client architectures.  It is perfect for someone who already has an ABL GUI fat client because they can upgrade selectively in stages without a major rewrite.  That is an important fraction of the ABL community, but by no means is it all of the ABL community.  We have had Java and .NET OpenClient for some time.  If you are such a fan of .NET, you really should be moving to .NET OpenClient since you can be on .NET 4 in no time at all and you may never get there with ABL GUI for .NET.  You would even be able to take advantage of the parallel processing stuff there which one can't hope to articulate with ABL until ABL itself gets multi-threaded.

It is also very clear that PSC will be doing something in the RIA space and that the only reason they haven't done so already is the lack of any convergence on a standard.  While PSC themselves hasn't moved forward here, individual companies and partners have produced their own solutions and are delivering product.

Given that diversity of solutions, it seems that it would be a major backward and limiting step to get into bed with MSFT.

It runs only on Windows for a couple of good reasons.

1. Currently, this appears to be acceptable to their market, i.e., demand for Linux exists, but is not yet compelling.

2. Traditional ABL GUI is Windows only, so programming for that on Linux would make no sense.

3. ABL GUI for .NET is so far Windows only, so programming for that on Linux would make no sense.

4. Programming for ChUI ABL on Linux would make sense, but ChUI ABL isn't much of a priority at PSC (inappropriately, perhaps).

But, Eclipse is Java, not .NET, so I don't know what your point is anyway.

Excuse me????   The current release of SQL is SQL-92 ... that's 1992!  PSC is way behind current SQL standard.  Did you notice that they recently released the world's first type 5 drivers ... but not for the OpenEdge database?  Yes, there are a couple of things in the SQL implementation that I wish we had in the ABL implementation ... It's Time applies to them too ... but I hardly think that you can characterize the SQL development as speeding forward while the ABL DB development is lagging ... been keeping up with ProDataSets, have you?

I didn't say that SQL was up to date, but that it was being developed  more than the ABL querying system (if SQL is outdated, imagine ABL :c) ).

I'd say that ProDataSets are there only to match .NET datasets (in particular because of OpenClient for .NET?), so I wouldn't consider this as ABL development (except maybe for the recursive fill).

My whole point is that they are already focusing their development effort on things that run on Windows, not Linux and not Unix either, so the point that they cannot go to .NET because they possibly wouldn't support all the platforms that they currently support is vain.

They already do almost nothing new in or for the ABL for other platforms.  They could as well freeze the AVM for other platforms and use the .NET VM for Windows and anywhere else that .NET maybe supported and their support for other platforms would be about the same as today (again, I'm talking about the ABL language, not any other Progress technology).

Again, they are already in bed with MSFT, so it would just be the natural thing to do.

This has been mentioned many times now ... here is another very active thread where it is becoming particularly impossible to follow the discussion.

Can't we have a better forum engine ? Where replies are sorted by date of posting. I think the hierarchical display of posts is useless. Including a quote of the previous message is enough.

PDS have been described as datasets on steroids, so I hardly think you can claim that they exist only for imitation and compatability.  You do know they have been around since 2003?

And since when do we have OpenClient for .NET?

Frankly, I don't know where you get your ideas.  Yes, the development effort for the ***development tools***, i.e., the IDE is focused on Windows and yes, ABL GUI for .NET is focused on Windows, but every other part of the development effort is applicable across platforms.  Do all the OO extensions seem like a trivial or Windows only addition to you?

Does Transparent Data Encryption seem like a SQL-only feature to you?

I think you would find quite a few people in Bedford and Nashua surprised to hear you say that.

Myself, I think they are "sleeping around".

My whole point is that they are already focusing their development effort on things that run on Windows, not Linux and not Unix either, so the point that they cannot go to .NET because they possibly wouldn't support all the platforms that they currently support is vain.

I think you are alone here. I am working with a number of customers where Windows for Dev tools and clients is acceptable but AppServer on Linux or Unix is a pure must have!

Having said that I also have other customers where .NET on the AppServer would be nice.

But the point is, that Progress should not give up on platform independence on the AppServer. Also for the announced OE11 features! So stopping ABL development on those platforms is a no-go.

You might want to experiment with going to Your Stuff => Preferences and selecting the Flat view instead of the Threaded view.  I wish one could select this for an individual display.

With a thread like this one, I end up using the browser search function to find some text from the e-mail notification.

1998, I believe.

It's hard to consider TDE as an ABL language improvement.. isn't it said that when code executes in the AVM, everything that runs in-memory is un-encrypted?

For the OO extension, they are being made compatible to .NET structures, but I think we already disagreed on this point earlier.  :c)

Weren't datasets part of the original version 1.0 of C# (Febuary 2002) ?

And since when can OpenClient pass a .NET dataset as a parameter to an ABL AppServer?

tamhas schrieb:
1998, I believe.

With .NET released in 2002 that would be a real surprise :-)

OpenClient for .NET is available since 10.0A like the ProDataset.

Thanks Thomas, I wasn't aware of this setting.

tamhas wrote:
You might want to experiment with going to Your Stuff => Preferences and selecting the Flat view instead of the Threaded view.  I wish one could select this for an individual display.
With a thread like this one, I end up using the browser search function to find some text from the e-mail notification.

OK, I'll update http://www.oehive.org/versionhistory to reflect that.

And yes you can exchange PDS with .NET, David ... see what you've been missing?

I just wanted to highlight the fact that ProDataSet are probably only there in the first place because of the .NET OpenClient.

TDE is not an ABL language improvement, but it is not focusing on SQL.

The OO implementation is not modeled on .NET.  It seems to me to be modeled on what the engineers think is good OO in the context of the existing ABL.  E.g., the new error handling is obviously influenced by Java Try/Catch, but shifted to have a block focus because historical ABL error handling is block oriented.

> E.g., the new error handling is obviously influenced by Java Try/Catch,  but shifted to have a block focus because historical ABL error handling  is block oriented.

And it is coincidentally compatible with .NET exception handling.

I think you just insulted Mary.

Is that someone working for Progress or the idol that cannot walk nor talk nor act?

Mary Szekely, e.g., http://communities.progress.com/pcom/docs/DOC-36278

Those who have been around the inside a while revere Mary.

Run !!, for the love of God, run. Hordes of the "Worshippers of Mary"

are after your hide ...

On 3 May 2010 19:24, Thomas Mercer-Hursh

Pardon my ignorance.  Is Gus worshipped also?

Note that the idea of taking something from .NET and making it better is great, it's exactly what I said about Infragistics controls that take on what is already there and offers something on top of it that is better.

That's also what I am suggesting that Progress do.  As I said : "that's why they could benefit from being .NET compatible and just adding  value over the .NET offer at each point in time, making ABL the best  language to deal with business data in particular with an OpenEdge DB".

And it is coincidentally compatible with .NET exception handling.

And with SoapExceptions. So what is the point? Most languages use CATCH and FINALLY nowadays. Makes understanding easier.

And the .NET Exception is lifted to be a Progress.Lang.Error as well.

"Worship" really isn't the right word (except in a "tongue in cheek" sense).

But many of us do have a lot of respect for both Mary and Gus.

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.

Alright, I'm giving you back your thread.

I certainly hope not.

-gus

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:

Example 1.

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.

Example 2.

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.

Maxim.

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.

community.progress.com/.../add_support_for_multithreading_in_openedge.aspx

I'd love to be able to use multi threading to be able to fire off background workers to do big chunks of processing for me. I have issues with large data grinding programs not responding if customer starts clicking trying to do something else and then just cancelling out as it's white screened.