D
dbeavon
Guest
Thomas, it sounds like you aren't quite sold yet on the idea of embedded databases - nor on keeping any persistent data outside of an OpenEdge database. But TT data is already being stored (cached locally) in a way that is similar to an embedded database... which is why I was trying to make some comparisons and suggest some improvements. >> The usual solution for that is to do the assembly on the AppServer and then only send a limited amount of data over the wire. No... because appserver *IS* over the wire. It is becoming more common to run an appserver on a machine that is different than the one hosting the database. PASOE is *NOT* considered to be an appendage of the database, or at least not as much as the "classic" appserver used to be. It is more scalable and fault-tolerant to create a *separate* tier where you would run PASOE servers, preferably several of them behind a load-balancer. You might even want to run them in docker containers. This is especially feasible if your PASOE servers and database are running within the same LAN, connected by 10Gbit ethernet. Remember that a database server is there to serve a *different* purpose than an appserver. The first one serves raw data and the second one incorporates business rules as well. But we may want to create a new thread for a long discussion about software architecture. >> send a limited amount of data over the wire This is the goal for any database server. The OE database in version 12 is making improvements in this area by supporting "server-side" joins which promise to send less data over the wire (to appserver) than what needs to be sent today. Less data will be sent to appserver, and it will be up to the ABL business rules (in appserver) to determine what kind of data is subsequently composed and sent along to client applications. >> Reconnecting to a prior session's TTs sounds like an EXTREMELY risky idea. How do you have any idea how current the data is? How current is TT data supposed to be? 10 seconds? 10 milliseconds? The exact same risk applies to all temp table data after it has been created. This same risk applies to all types of caching as well. It is up to the implementation of the cache to expire whenever the source data changes, or after a reasonable timeout. Besides it is not less risky than some of the other things we do in ABL on a regular basis. For example we make use of *tons* of data that is retrieved from the database using "NO-LOCK". That NO-LOCK data is very similar to a dirty cache and it can be just a "risky". (If you work with ABL long enough, you will have your own stories about the consequences of retrieving tons of data with NO-LOCK.) I'm not suggesting that everyone should keep their TT data around all week or all day long. But it would be nice to have features that make temp-tables more flexible. As I mentioned before, the concept of temp-tables is not unique to ABL. Temp tables behave very similar to an embedded database (ie. like SQLite). Note that SQLite may be the most widely deployed database in the world*** and it would be extremely helpful to interoperate with something like that from ABL. *** see sqlite.org/mostdeployed.html
Continue reading...
Continue reading...