Re: Newbie design question

Ashley,



GigaSpaces "specific iterator" - The GSIterator, is based on JavaSpaces05
match set specification. Based on the given template collection, it fetch
first the UIDs of all matching entries from the space and later using
sliding window approach deliver batches of matching entries back into the
client. With this approach both client and space do not allocate memory to
deliver large result set into the application. With the GSIterator you can
determine the batch size - so we can control the amount of data the client
will pull from the space when every batch is consumed. This approach allows
you to deal with large result sets without loading the space and client
memory and CPU. The GSIterator support also blocking operations - i.e. you
may wait for a specific amount of time for a matching entry to be written
into the space while iterating the constructed iterator.

See more at:

http://www.gigaspaces.com/wiki/display/GS/JavaSpaces+Iterator



The GSIterator ensures the client will read each entry only once.



Another special mode to ensure an entry will be read only once can be done
by using GigaSpaces 5.2 exclusive read lock mode. See:

http://www.gigaspaces.com/wiki/display/GS/Exclusive+Read+Lock



It is not clear what do you mean by "one worker per entry approach" -
GigaSpaces support connection multiplexing and different thread pool for
every space module. You can control the thread pool size. Can you provide
more info about the exact scenario?



Shay



  _____

From: Ashley Williams [mailto:[email protected]]
Sent: Monday, January 29, 2007 4:18 AM
To: [email protected]
Subject: Newbie design question



Hi,



As a company we are fairly new to javaspaces and I have a design issue I'm
hoping somebody can shed some light on. Essentially we have a javaspace
populated with an extremely high number of entries that are requested from
time to time by some other stateless components - and so we regularly read
them and then pass the details on to the interested components. In order to
do this we take advantage of the 'read multiple' capabilities of the
gigaspaces implementation we are using. However, the higher the number of
template matches we get the less feasible this approach becomes as we are
holding onto a high number of entries in memory in one go.



I can imagine a number of traditional approaches to this problem, such as
doing many read multiples against a managable buffer size or using the
gigaspaces specific iterator. But I can't shake the feeling that this isn't
in the spirit of JavaSpaces as my first instinct (having read one JS book)
would be to throw a capped number of workers at the space each handling one
entry at a time. This also presents a few problems which is where you guys
come in ;)



1. How do we ensure that we read each entry just the once - maybe we need to
manage a sequence number? It would be great if there was some java
collections equivalent library for managing distributed data structures so
that we don't have to keep reinventing the wheel.



2. With a one worker per entry approach do folk find that threading
performance of the JVM is an issue? We are using Java 5 at the moment.



3. Maybe I haven't got the right end of the stick after all because rumor
has it that read multiple capabilities are being considered for inclusion
into the JavaSpaces specification also.



I'm not overly concerned with the gory details at the moment but any design
pointers would be greatly appreciated!



- Ashley

DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful. Please inform the sender and delete the message
immediately from your system. This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.

===========================================================================
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