I'd like to start this happy new 2019 with a question that was somehow missed at the PUG Challenge in Dublin :
So engineering announced that thanks to the new OE12 DB engine to come we will no longer deal with a (large) set of _mproserve processes but with one single multi-threaded process. Fine. Perhaps I even heard we would no longer use shared memory connections with this single process.
How about our current AppServers or a batch sessions running on our DB machines with a shared memory connection with great performances ? (no -H and no -S but path to physical DB). Is the idea to always go through the local TCP loop ?
Not sure who you heard this from. In OE12.0 you have many options.
"we will no longer deal with a (large) set of _mproserve processes but with one single multi-threaded process"
This is completely up to you based on how you configure your deployment. One threaded ABL database server (_mtprosrv) or many threaded ABL Database servers and SQL database servers or one or many non-threaded ABL database servers or some mix in between. However I would as always be cautious of putting all your eggs in one basket.
" I even heard we would no longer use shared memory connections with this single process"
This is not true. The threaded database server uses shared memory to communicate between other servers and non-networked utilities at least. If there are self service _progress connections or self service PASOE connections then shared memory will be used for coordination of the shared resources.
One of the reasons for the threaded ABL database server is to remove the performance impediment preventing users from deploying in an environment that horizontally scales, not to limit it to TCP only connections.
"How about our current AppServers or a batch sessions running on our DB machines with a shared memory connection with great performances ? (no -H and no -S but path to physical DB). Is the idea to always go through the local TCP loop ?"
Shared memory connections for PASOE, batch sessions and utilities are certainly supported in OE12.0.
Not sure who you heard this from. In OE12.0 you have many options.
"we will no longer deal with a (large) set of _mproserve processes but with one single multi-threaded process"
This is completely up to you based on how you configure your deployment. One threaded ABL database server (_mtprosrv) or many threaded ABL Database servers and SQL database servers or one or many non-threaded ABL database servers or some mix in between. However I would as always be cautious of putting all your eggs in one basket.
" I even heard we would no longer use shared memory connections with this single process"
This is not true. The threaded database server uses shared memory to communicate between other servers and non-networked utilities at least. If there are self service _progress connections or self service PASOE connections then shared memory will be used for coordination of the shared resources.
One of the reasons for the threaded ABL database server is to remove the performance impediment preventing users from deploying in an environment that horizontally scales, not to limit it to TCP only connections.
"How about our current AppServers or a batch sessions running on our DB machines with a shared memory connection with great performances ? (no -H and no -S but path to physical DB). Is the idea to always go through the local TCP loop ?"
Shared memory connections for PASOE, batch sessions and utilities are certainly supported in OE12.0.
adding to what rich said,
in current and past (i.e. long before 11.7) releases, appservers and batch processes can already use shared memory database connections.