Re: FW: Inserting single semaphore into the JavaSpace

After thinking for a while that I must be boring the whole world with my=20
stuff to death since no one replies I realized that several mails in=20
response to my question have arrived but have ended up in the spam folder=
...

Looking on Dan Creswell's homepage for that LockManager I found this=20
article:=20
http://www.jroller.com/dancres/entry/implementing_a_remote_object_with=20
This made me realize that I can implement the same thing I did with the=20
RMI registry with JERI:

public class AmIFirstRemote implements Remote
{
}

Exporter myExporter =3D new=20
BasicJeriExporter(TcpServerEndpoint.getInstance(0), new=20
BasicILFactory(), false, true);

        AmIFirstRemote myServer =3D null;

        try
        {
            myServer =3D new AmIFirstRemote ();
            myExporter.export(myServer); // first time
        }
        catch (ExportException e)
        {
            e.printStackTrace();
        }

        try
        {
            myServer =3D new AmIFirstRemote ();
            myExporter.export(myServer); // second time --> exception is=20
thrown
        }
        catch (ExportException e)
        {
            e.printStackTrace();
        }

The second time I call myExporter.export(myServer) I get a=20
java.lang.IllegalStateException with the message "object already=20
exported via this exporter". This is exactly what I want to solve my=20
problem.

The client that is able to export aAmIFirstRemote without facing an=20
exception is the first one to export this object. It then writes=20
anInitialSemaphoreExistsEntry to the space, which is never removed from=20
it, an the initial semaphore as well and unexports the AmIFirstRemote=20
(to clean up things). Any client that starts up, first checks whether it=20
finds the InitialSemaphoreExistsEntry in the space. If so, someone else=20
has inserted the initial semaphore already and there is no need to=20
export anAmIFirstRemote and all that. If the inital semaphore doesn't=20
exists in the space, it's only because someone else did a down on it.

So, I'm quite happy now with this solution. With JERI the user also=20
doesn't have to specify on what machine and port the RMI registry=20
resides. Contrary to the RMI registry JERI is also a lot faster. Doing a=20
LocateRegistry.getRegistry(rmiPort) or=20
LocateRegistry.createRegistry(rmiPort) in RMI takes several seconds and=20
binding a remote object to the registry as well (on my stand-alone=20
computer!?). I was always looking for someone who could explain this to=20
me...

@Tom: Thanks for your suggestion. To be really honest I only understand=20
part of it. Might be because I have to little background knowledge of=20
Jini and JavaSpaces ... Mea culpa.

Regards, Oliver Plohmann

Tom Hobbs wrote:
> Sorry, just realised that I failed to send this to the list.
>
> Gregg get's two apologies because he's going to get this email twice=20
> now...
>
> Tom
>
>
> -----Original Message-----
> From: Tom Hobbs
> Sent: 17 October 2008 17:07
> To: '[email protected]' <mailto:%[email protected]%27>
> Subject: RE: Inserting single semaphore into the JavaSpace
>
> A simple solution which I've come across (and we use successfully=20
> within my company) is a two-fold solution.
>
> The first is a flag on the JavaSpace that indicates that it is=20
> "Available", that is, it is ready to be discovered/used. The second is=20
> the concept of a post-start operation.
>
> For example, the code to start your JavaSpace might look something=20
> like this;
>
> NonActivatableServiceDescriptor.Created c =3D=20
> (NonActivatableServiceDescriptor.Created) sd.create(javaSpaceConfig);
> JavaSpace js =3D (JavaSpace) c.proxy;
> js.write(...); //put the token in
> makeAvailable(js);
>
> Where "makeAvailable(js)" is a method which adds an=20
> initialLookupAttribute to the supplied service (in this case a space).=20
> The attribute might be something as simple as "new Comment("Available")=
".
>
> Other code changes that are required is when your other services are=20
> looking for this space the service validator they use must only return=20
> a JavaSpace which has the "Available" comment in its=20
> initialLookupAttributes.
>
> What this gives you is that your JavaSpace is only every eligible for=20
> discovery when it is in a known good state - in this case it has the=20
> token inside it. Your services now never have to worry about putting=20
> the first token in themselves.
>
> We find this solution very simple and it meets our needs. The only=20
> real overhead is the extra check in the Service Validator when=20
> discovering services - and that itself is pretty small.
>
> Hope this makes sense.
>
> Tom
>
>
> -----Original Message-----
> From: Gregg Wonderly [mailto:[email protected]]
> Sent: 17 October 2008 15:39
> To: [email protected] <mailto:[email protected]=
>
> Subject: Re: Inserting single semaphore into the JavaSpace
>
> You said without another service... Dan Creswell has a distributed=20
> lock manager
> on his web site that works. I have one as well that is a little=20
> different in
> design, using Jeri for communications instead jgroups. But, in the=20
> end, its
> something that is generally useful. I had some thoughts about how to=20
> do this
> using Javaspaces, but have never had a chance to explore the ideas to=20
> see if
> they'd work.
>
> Gregg Wonderly
>
> Oliver Plohmann wrote:
> > Hello,
> >
> > thanks for the link. The article explains the idea of a token used as=
 a
> > semaphore. This is what I saw in Freeman's book and that's how I inte=
nd
> > to do synchronization. Problem is that someone must be the first one =
to
> > insert the >single< semaphore entry into the space since it is empty =
to
> > begin with. Now there might be several clients using the space and=20
> there
> > must be one of them who will insert the initial semaphore. How do the=
y
> > agree on who will do this when an initial semaphore not yet exists in
> > the space to prevent race conditions from happening when working out=20
> the
> > agreement who will be the one?
> >
> > As explained I use the RMI registry as a workaround to determine who =
is
> > the first one (everyone that comes second faces a=20
> AlreadyExistsException
> > when binding a remote object to the registry that already exists ther=
e
> > with the same name) and thus is allowed to write the initial semaphor=
e
> > to the space.
> >
> > I feel a method like
> >
> > writeOnce(Entry entry, Transaction trx, long timeout) throws
> > EntryAlreadyExistsException
> >
> > would be a nice thing to have in the JavaSpace interface. Many
> > concurrency issues could be solved easily this way and efficiently.
> > Maybe there is still someone who has had this problem as well and fou=
nd
> > a simple quick solution.
> >
> > Thanks, Oliver Plohmann
> >
> > Holger Hoffst=E4tte wrote:
> >> Oliver Plohmann wrote:
> >>
> >>> I need to have for certain operations exclusive access to the=20
> JavaSpace
> >>> or at least part of it. [..]
> >>>
> >>
> >> There is a "discussion" with a pointer to an article on TSS:
> >> http://www.theserverside.com/common/printthread.tss?thread_id=3D4541=
8
> >>
> >> This should do what you want.
> >>
> >> -h
> >>
> >>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=20
>
> >>
> >> To unsubscribe, send email to [email protected]=20
> <mailto:[email protected]> and include in the
> >> body
> >> of the message "signoff JAVASPACES-USERS". For general help, send
> >> email to
> >> [email protected] <mailto:[email protected]> and include in=20
> the body of the message "help".
> >>
> >> To view past JAVASPACES-USERS postings, please see:
> >> http://archives.java.sun.com/archives/javaspaces-users.html
> >>
> >>
> >
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> To unsubscribe, send email to [email protected]=20
> <mailto:[email protected]> and include in the body
> of the message "signoff JAVASPACES-USERS". For general help, send email=
 to
> [email protected] <mailto:[email protected]> and include in=20
> the body of the message "help".
>
> To view past JAVASPACES-USERS postings, please see:
> http://archives.java.sun.com/archives/javaspaces-users.html
>
> www.sucden.co.uk <http://www.sucden.co.uk/>
>
> Sucden (UK) Limited, 5 London Bridge Street, London SE1 9SG
> Telephone +44 20 7940 9400
>
> Registered in England no. 1095841
> VAT registration no. GB 446 9061 33
>
> Authorised and Regulated by the Financial Services Authority (FSA) and=20
> entered in the FSA register under no. 114239
>
> This email, including any files transmitted with it, is confidential=20
> and may be privileged. It may be read, copied and used only by the=20
> intended recipient. If you are not the intended recipient of this=20
> message, please notify [email protected] _immediately and=20
> delete it from your computer system.
>
> We believe, but do not warrant, that this email and its attachments=20
> are virus-free, but you should check.
>
> Sucden (UK) Ltd may monitor traffic data of both business and personal=20
> emails. By replying to this email, you consent to Sucden's monitoring=20
> the content of any emails you send to or receive from Sucden. Sucden=20
> is not liable for any opinions expressed by the sender where this is a=20
> non-business email.
>
> The contents of this e-mail do not constitute advice and should not be=20
> regarded as a recommendation to buy, sell or otherwise deal with any=20
> particular investment.
>
> This message has been scanned for viruses by Mimecast=20
> <http://www.mimecast.com/>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=20
> To unsubscribe, send email to [email protected] and include in the=20
> body of the message "signoff JAVASPACES-USERS". For general help, send=20
> email to [email protected] and include in the body of the message=20
> "help".
>
> To view past JAVASPACES-USERS postings, please see:=20
> http://archives.java.sun.com/archives/javaspaces-users.html
>

--=20

www.objectscape.org

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the bo=
dy
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