Welcome to our FAQ page, just click the mouse on a question to see it's answer.
|
Q.
Is Persistore a database?
|
|
A.
No. Persistore provides flexible and high performamce data persistence, but is not a relational database.
However Persistore is designed for storing data in a flexible manner; it supports the persisting of .NET objects
as well as shared variables (including arrays). A Persistore repository supports directories (akin to folders)
in which you may store other directories, .NET objects, shared variables and arrays (value types) as well as arbitrary
named memory blocks.
The product also supports versioning of .NET objects allowing multiple versions of classs to co-exist in the repository.
|
|
Q.
Persistore is described as using 'shared memory' what is that?
|
|
A.
Shared memory (also called memory mapping) is a fundamental mechanism found in most modern operating systems.
There are two key mechanisms that it provides a) the ability for programs/applications to explicitly share areas of
their memory space and b) the ability to automatically have memory directly backed up to a local disk file.
Persistore makes it very easy for developers to use either or both of these features in their own applications. Shared memory is considered to be the
fastest form of inter-process communication (IPC). |
|
Q.
Why should I consider using Persistore in my application?
|
|
A.
Persistore makes it possible for applications to read, write and update objects
used by your application. Because of its unique design it is able to do this very rapidly and with complete resilience.
Unlike alternative methods of persistence, Persistore deals only with chunks of memory and these are completely managed
by the library in real-time. Your application remains unaware of the organization
or location of the memory nor does it need
to concern itself with IO or files. Persistore is easily able to persist very large object structures and can persist
data for any number of distinct applications in a single repository file. In some ways a Persistore repository file is similar
to a disk drive from the point of view of flexibility.
|
|
Q.
Can Persistore help with my ASP.NET projects?
|
|
A.
Absolutely! In fact this is one of the most effective ways that Persistore can be used. ASP.NET applications often have
demanding performance requirements, and the need to move data to/from external databases is often one of the most
expensive activities. Persistore can serve as an object repository enabling your application to simply read/write/update
.NET objects directly. Remember that this is a very fast operation in Persistore and involves no IO. Because a Persistore application
(and this includes ASP.NET web applications) stores data inside the applications memory, the performance gains are very
often considerable. However Persistore can do more than simply object persistence; because it can also access and update shared
memory variables - directly in memory - it can enable your web application to attain very high levels of performance.
A simple example is a site hit counter, Persistore makes this just a single line of code in C# or VB that increments
the shared counter, yet provides complete resilience against process failure all without the need to do any IO !
|
|
Q.
I can already serialize objects to a file, so in what way is Persistore an advantage?
|
|
A.
Yes you can and it is easy in .NET to serialize objects to a file. However this approach to object persistence
becomes very limiting when dealing with multiple objects or performance sensitive applications. Imagine your application needs
to store many different objects, and that it also may need to modify these object in unexpected ways. If your app must update persisted objects
then it has to handle the change in length that this can entail. If several objects were persisted to a single file, it would be very
complex to implement this, using a single file for each object introduces it's own logistical problems. Furthermore reading and writing a
file every tine an object is updated results in significant IO overhead.
Trying to flexibly manage this with potentially hundreds of objects and possibly many applications becomes an expensive activity from
both a developmental and operational standpoint.
Persistore lets you forget about all these issues and simply read/write/update your objects. Mixing multiple objects even of differing classes
in a single repository is trivial with Persistore and because there is no IO the whole operation is much quicker.
|
|
Q.
So because Persistore uses 'shared memory' does this mean several applications can share my data?
|
|
A.
Yes. Persistore provides a wealth of features that allow you to exploit shared memory. Persistore allows applications
and processes (including Windows OS services, web services and ASP.NET applications) to communicate extremely quickly
with no need for files, pipes, TCP, UDP etc. A web application for example, could write objects into a Persistore repository
whilst a seperate application or process reads that data and processes it. This can result in responsive web sites because IIS incurs
very little delay when your code persists an object. Furthermore by using shared variables one can attain the highest levels of
IPC because unlike object persistence there is no serialization, instead the data is accessed and modified in-memory in real-time.
|
|
Q.
How does Persistore let me access shared memory?
|
|
A.
There are several ways you can access and manipulate shared areas of memory. One of the easiest is to create shared variables or shared arrays.
You can create shared variables for any of the .NET value types (char, byte, bool etc) as well as strings. Once created any thread in any process may access
the underlying data quite naturally, simply by using the shared variable; a shared variable is a special kind of object that encapsulates
memory and provides type specific operations that let you get at the variables value, perform arithmetic upon it etc.
Persistore also allows you to create arbitary areas of untyped storage which you may access through pointers using strucs and unsafe C# features;
such memory access allows very high performance IPC systems to be constructed.
Shared variables and areas are not based upon object serialization, they are intended for situations where direct and rapid access to memory is
required; the memory is (optionally) fully persistent however.
|
|
Q.
It seems that 'persistence' is an option, can you explain?
|
|
A.
Persistore allows applications to exploit some or all of the operating systems memory mapping features. If it is required for
applications to be able to share data easily without any need for it to be retained or preserved, then this is easily
acomplished. Persistore refers to this as a 'volatile' repository. Volatile repositories support all of the features that persistent
repositories do, they simply do not have any kind of backing file on disk and consequently any data in the repository
is lost when the last process unloads it. |
|
Q.
Can you give an example of using a shared variable?
|
|
A. Yes we can. A simple but very useful application is the use of shared
variables for real-time configurability. By storing configuration data in shared
variables, it is easy to write stand-alone confguration tools. An example might
be some kind of server process, perhaps one that runs as a service. By using shared
variables to store logging options (for example) one is able to change these options
simply by modifying the shared variables. There is no need to do any kind of file
IO and there is no need for the application to include any code for refreshing itself
etc. Because shared variables are truly shared, any changes made by one application
are immediately visible to all other applications. How many times have you wished
you could add some debugging flags etc to an application, that can be swicthed on/off
whilst the application is running? Well this is now a trivial thing with Persistore.
In fact the Persistore Analyzer already has the capability for you to 'edit' simple
shared variables so in most cases there is no need to write any configuration tool
of your own. |
|
Q.
Does Persistore include any ASP.NET Provider classes to help with my development?
|
|
A. Absolutely. We already have implementations of the MembershipProvider and
SessionStateStore provider classes; these classes give you the ability to manage user authentication
and session state management in a real-time memory resident object repository. You can thus
take immediate advantage of Persistore in new or existing web applications without writing any code. |