Re: preallocating memory used by javaspace

Dan,



Your question is in fact very good one.

You should know that in the software industry you build a product on top of
some specification and add your own flavor into it.

Take for example IBM webshpere , BEA Weblogic and JBoss Application Servers.
All these following the J2EE Spec. Are you sure all of them got the exact
set of features?

Same for Oracle , DB2 and MSSQL - all of them support SQL. Are you sure all
of them got the exact features?

Still, users do move between them. It is up to the architecture to decide
which features he wants to use - but the basic core features are exactly the
same.



Jini/JavaSpace is a great technology and one of the most simplistic and
powerful specs I have seen.

Still , in order to build enterprise scale applications architects and
develops need a product that cover their needs.



This is what GigaSpaces all about - The core that is powerful JavaSpace
implementation (that you can get for free as part of the community edition
that includes in fact most of the options I listed below) and a
sophisticated Service Grid using Jini and Rio that allows you to deploy your
application into the Grid. The space will be started for you and injected
into the Service itself. Your space entries and Application Services can be
pure POJOs - no need to implement any interface to write entries into the
space or to deploy your classes as Services.



You may access the space using JavaSpaces , SQL , Map , JMS or JDBC with
Java , C++ and C# utilizing GigaSpaces as Grid enabler using master/worker
framework , Service Bus or a distributed Cache. All the above are wrapped
with Spring templates to provide one common ground for developers to start
with. This means you can use Standard Spring templates for all the above. To
allow the In Memory Data Grid we interact implicitly with external data
sources you can plug-in your database DAOs using Hibernate and allow the
space to read data or write data into the database - in sync or async
manner.

See:

http://www.gigaspaces.com/wiki/display/GS/5.1



The above includes the latest info about our 5.1 release. See POJO , Spring
, CacheLoader/Store , Mirror , PONO , POCO and many more.



In terms of performance - in general all APIs provide more or less the same
performance - simply because they are built on top of the JavaSpace API that
is the super set of all other API's. Quick performance numbers:

In embedded mode Space API - 100K operations per second , strict remote mode
5K operations per second , send and forget remote mode 20K operations per
second - All these for one space. For Map API users we got special
optimization that allows us to provide local cache that provides the same
performance as Hash table. The local cache is sync with the master space.
You can scale and use the clustered partitioned space and start new services
on the fly based on SLA to process the incoming requests to accommodate your
needs - so there is no limit to the throughput you can get from the system.



Why users would need to debate with the vendor locking question when they
get exactly what they need , especially when all what GigaSpaces provides is
build on top of industry standards and exposing only standard APIs? See the
effort we put into supporting POJO both at the Data Grid layer and the
Service Grid layer - No need to implement any special interfaces! Even not
to implement the Entry interface to write entries to the space! The
architect and developer fantasy becomes the reality!



As part of my job I'm visiting customers and prospects around the world -
when presenting the above I never got the vendor locking question.



Hope the above clarifies our approach and answer your questions.



Regards,

Shay





-----Original Message-----
From: Dan Creswell [mailto:[email protected]]
Sent: Friday, September 01, 2006 9:39 AM
To: [email protected]
Subject: Re: preallocating memory used by javaspace



Hmmm,



But aren't all of those specific to your product?  That would mean lock-in
from a user perspective due to use of non-standard features.

I'm not saying people shouldn't go that way but I'd like to get a clear
understanding of what we're trying to achieve here before making any talking
about implementation options.

In particular, I'm worried about what performance expectations there might
be, how important continued processing of requests is etc.



Best,



Dan.



Shay Hassidim wrote:

> xaea ,

>

>

>

> Take a look on the Cache Policy , Persistent space , CacheLoader ,

> CacheStore , Memory usage ,  Memory Control and Mirror Service at

> GigaSpaces.

>

> Just search the help with the above:

>

> www.gigaspaces.com/wiki

>

>

>

> shay

>

>

>

>

>

>

>

> -----Original Message-----

>

> From: Dan Creswell [mailto:[email protected]]

>

> Sent: Wednesday, August 30, 2006 3:12 PM

>

> To: [email protected]

>

> Subject: Re: preallocating memory used by javaspace

>

>

>

> Gregg Wonderly wrote:

>

>>  xaea alvein wrote:

>

>> > no, it's preallocate. i'm considering setting a "quota"/"capacity" for

>

>> > the

>

>> > space, so that the memory taken by it won't exceed some x MB. is it

>

>> > possible?

>

>>

>

>>  What will you expect the application to do when this limit is reached

>

>>  because of

>

>>  an imbalance between producers and consumers?

>

>>

>

>

>

> Gregg is heading along the right lines so more generally:

>

>

>

> When this quota is reached what would you wish to happen?

>

>

>

> Should the space stop accepting more entry's?

>

>

>

> Should the space swap to disk?

>

>

>

> Should the space signal the application in some way?

>

>

>

> Should the application do something to manage this situation itself

>

> perhaps by adopting quota's within it's own code?  If not, why not?

>

>

>

> What do you expect to happen to throughput in these circumstances?

>

>

>

>

>

> Dan.

>

>

>

>
===========================================================================

>

> To unsubscribe, send email to [email protected] and include in the
body

>

> of the message "signoff JAVASPACES-USERS".  For general help, send email
to

>

> [email protected] and include in the body of the message "help".

>

>

>

> To view past JAVASPACES-USERS postings, please see:

>

> http://archives.java.sun.com/archives/javaspaces-users.html

>

>
===========================================================================

> To unsubscribe, send email to [email protected] and include in the

> body of the message "signoff JAVASPACES-USERS". For general help, send

> email to [email protected] and include in the body of the message

> "help".

>

> To view past JAVASPACES-USERS postings, please see:

> http://archives.java.sun.com/archives/javaspaces-users.html

>



===========================================================================

To unsubscribe, send email to [email protected] and include in the body

of the message "signoff JAVASPACES-USERS".  For general help, send email to

[email protected] and include in the body of the message "help".



To view past JAVASPACES-USERS postings, please see:

http://archives.java.sun.com/archives/javaspaces-users.html


===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html