Hi,

I am still using 2.11 b3 and planning to move on with 2.13 (need to renew my support plan).  However, I read a couple of months ago that there will be a change in the visibility of memory tables to other sessions so I want to confirm the following:

Are the memory tables visible to other sessions?  In other words, if create a memory table and name it "XXX" using one session can this table be created with the same name at the same time using another session?

One more thing, according to the Roadmap "Messaging layer for general messaging notifications and broadcasts with the ElevateDB server" will be support it in 2.14.  Is this still the plan? and when can we expect 2.14?

Regards,
Abdulaziz Jasser

Abdulaziz


>I am still using 2.11 b3 and planning to move on with 2.13 (need to renew my support plan). However, I read a couple of months ago that there will be a change in the visibility of memory tables to other sessions so I want to confirm the following:
>
>Are the memory tables visible to other sessions? In other words, if create a memory table and name it "XXX" using one session can this table be created with the same name at the same time using another session?

Yes - for c/s it happened in v2.12

>One more thing, according to the Roadmap "Messaging layer for general messaging notifications and broadcasts with the ElevateDB server" will be support it in 2.14. Is this still the plan? and when can we expect 2.14?

Only Tim can answer that. His usual response to timescales boils down to "when its ready"

Roy Lambert [Team Elevate]

Abdulaziz Jasser wrote:

>>Are the memory tables visible to other sessions?  <<
Yes

>>In other words, if create a memory table and name it "XXX" using one session can this table be created with the same name at the same time using another session?<<

No. If session #1 creates a Memory table named "XXX" and session #2 tries to create a Memory table with the name "XXX", it will fail because the memory table already exists in the database. This is similar to what would happen if  it was a disk-based table. The memory tables are now visible to all sessions so session #2 should  check to see if table "XXX" exists before he tries to create it.

Keep in mind though, memory tables are stored in a "Memory" database that is separate from disk-based databases. So you could have table "XXX" in the memory database and table "XXX" in the disk-based database at the same time (because they are different databases).

But if you want the memory table to be visible only to the current session (like it was before), just create a Temporary memory table and no other session will see it.

I hope this helps.

Barry

Abdulaziz,

<< Are the memory tables visible to other sessions?  In other words, if
create a memory table and name it "XXX" using one session can this table be
created with the same name at the same time using another session? >>

Yes, that is the way that it now works.

<< One more thing, according to the Roadmap "Messaging layer for general
messaging notifications and broadcasts with the ElevateDB server" will be
support it in 2.14.  Is this still the plan? and when can we expect 2.14? >>

Yes, I'm working on the new comms layer right now.  It's going slow, but I'm
getting there.  It's a big change from the way that ElevateDB has
traditionally worked with the thread-per-connection model, but it will
result in a lot less memory consumption per session and better use of
multiple CPUs, in addition to providing the real-time messaging.

Tim Young
Elevate Software
www.elevatesoft.com

Abdulaziz,

Also, as Barry indicated, just use this:

CREATE TEMPORARY TABLE MyTable.....

from within any in-memory database, and the effect will be an in-memory
table that *isn't* visible to other sessions.

You have the best of both worlds now - session-specific and global in-memory
tables.

Tim Young
Elevate Software
www.elevatesoft.com

Roy,
Barry,
Tim,

Thanks for the clarifications.  So all I need is to add "TEMPORARY" word to the procedure that I used to create all the memory tables in my application.  LONG LIVE UNIVERSAL PROCEDURES


Regards,
Abdulaziz Jasser