Fernando,

<< The only advantage of such a change would be to have the possibility to
share memory databases, but it would also mean we can't count on the
isolation that we have now, and the process isolation is sometimes useful.
The ideal would be to have both, and let the user choose the isolation level
when the database is created, but I'm not sure if it's worth the extra code
in the engine... In my opinion it doesn't, but that's only my opinion of
course. >>

It's not a huge coding effort, either way.  My biggest concern is resolving
the possibility of incremental memory consumption over time, thus causing
issues with 24/7 usage over long periods of time.

<< I can live with that tiny memory leak and after all we know how to avoid
it.  Also, you will still have to decide when to drop the memory database
catalogs, and if the isolation level is not the client process then when are
you going to drop the catalogs ? >>

If I were to switch EDB to using shareable in-memory databases, then the
in-memory database catalogs would only get deleted when the EDB Server
process terminates.  That seems like a big deal until you realize that there
would only be one copy per in-memory database and that's it.  Currently,
there's a separate copy for each client process (computer name+process ID).

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

>If I were to switch EDB to using shareable in-memory databases, then the
in-memory database catalogs would only get deleted when the EDB Server
process terminates.  That seems like a big deal until you realize that there
would only be one copy per in-memory database and that's it.  Currently,
there's a separate copy for each client process (computer name+process ID).<

So if the remote client applications keep referring to the same set of in-memory databases with the same names (like memAccounting, memSales, memPersonnel, mem_1 etc.), everything should be fine.

It is only if the remote client application creates many randomly named temporary memory databases like "memAE98324FD" on the server it will accumulate the these memory database catalogs in memory when they are no longer needed by the application. Correct?

If so, I don't see a problem with that. The benefits more than outweigh the risks which can be controlled by not creating randomly named memory databases on the server.

Barry

Tim,

Say no more

--
Fernando Dias
[Team Elevate]

Barry,

<< So if the remote client applications keep referring to the same set of
in-memory databases with the same names (like memAccounting, memSales,
memPersonnel, mem_1 etc.), everything should be fine. >>

Yep.

<< It is only if the remote client application creates many randomly named
temporary memory databases like "memAE98324FD" on the server it will
accumulate the these memory database catalogs in memory when they are no
longer needed by the application. Correct? >>

Yep.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< So if the remote client applications keep referring to the same set of
in-memory databases with the same names (like memAccounting, memSales,
memPersonnel, mem_1 etc.), everything should be fine. >>

<Yep.>

<< It is only if the remote client application creates many randomly named
temporary memory databases like "memAE98324FD" on the server it will
accumulate the these memory database catalogs in memory when they are no
longer needed by the application. Correct? >>

<Yep.>

A shareable memory database can be quite useful at times. And you've got me thinking, which can be a dangerous thing at times  

Here is my thinking. If someone needed a very fast db server (say on a website), why couldn't someone replicate a disk based db server over to a RAM based db server? Assuming of course the RAM based server would hold either readonly data, or if the updates aren't critical, replicate the updates back to the disk based server?

Would this work?

TIA
Barry

Barry,

<< Here is my thinking. If someone needed a very fast db server (say on a
website), why couldn't someone replicate a disk based db server over to a
RAM based db server? Assuming of course the RAM based server would hold
either readonly data, or if the updates aren't critical, replicate the
updates back to the disk based server?

Would this work? >>

Sure, it would work great.   Plus, EDB allocates in-memory files in 64k
pages, so memory allocation would be nice and linear and would behave good
in a very large address space, such as that given by a 64-bit process.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

Barry,

<< Here is my thinking. If someone needed a very fast db server (say on a
website), why couldn't someone replicate a disk based db server over to a
RAM based db server? Assuming of course the RAM based server would hold
either readonly data, or if the updates aren't critical, replicate the
updates back to the disk based server?

Would this work? >>

<Sure, it would work great.   Plus, EDB allocates in-memory files in 64k
pages, so memory allocation would be nice and linear and would behave good
in a very large address space, such as that given by a 64-bit process.>

Then full speed ahead and get this implemented in v2.

For EDB v3 you may get a few ideas from MySQL's Cluster Database technology which replicates data to (mostly) memory databases. It is used by firms with large databases that require data redundancy with fail over to deliver reliable 24x7 operation. It is a bit hairy the way they implement it, but EDB v3 could offer a scaled down version of it. - Just a thought.

Barry

Barry,

<< For EDB v3 you may get a few ideas from MySQL's Cluster Database
technology which replicates data to (mostly) memory databases. It is used by
firms with large databases that require data redundancy with fail over to
deliver reliable 24x7 operation. It is a bit hairy the way they implement
it, but EDB v3 could offer a scaled down version of it. - Just a thought. >>

Thanks, I'll check it out.

Tim Young
Elevate Software
www.elevatesoft.com