Re: preallocating memory used by javaspace

Hi Shay,

I'm very aware of the need for vendors to do the things they do, it's
all part of doing business.  And I have no issue with that.

My only concern in all of this is to make sure we understand what the
user wants and what their solution boundaries might in terms of cost,
lock-in etc.  Then we can provide a good answer to their question.

Thus, when you talk about value add features as below, it's important
that we understand whether they are relevant or not and the tradeoffs
involved.  And if we're not clear what the user wants we can't make such
judgements.

I take your point that people do move between database implementations
but I think you'd agree it's a pretty rare thing because, as we all
know, it's hard.  And it's made harder by features that exist in one
product but not another.

I'd have to say that I'm surprised you haven't faced the vendor lock in
question as myself and a number of architects I know working in banks,
telco etc all have that question high on their list.

Best,

Dan.

Shay Hassidim wrote:
> 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