Re: FW: Inserting single semaphore into the JavaSpace

Oh no ... Just realized that I don't get my exception when I do this:

myExporter =3D new BasicJeriExporter(TcpServerEndpoint.getInstance(0), ne=
w=20
BasicILFactory(), false, true);
myServer =3D new AmIFirstRemote();
myExporter.export(myServer);

myExporter =3D new BasicJeriExporter(TcpServerEndpoint.getInstance(0), ne=
w=20
BasicILFactory(), false, true);
myServer =3D new AmIFirstRemote();
myExporter.export(myServer); // NO exception: am not using same instance=20
of BasicJeriExporter

It is only thrown when this is executed:

myExporter =3D new BasicJeriExporter(TcpServerEndpoint.getInstance(0), ne=
w=20
BasicILFactory(), false, true);
myServer =3D new AmIFirstRemote();
myExporter.export(myServer);
myExporter.export(myServer); // exception

Don't count your chickens before they are hatched...

/Olli


Oliver Plohmann wrote:
> After thinking for a while that I must be boring the whole world with=20
> my stuff to death since no one replies I realized that several mails=20
> in response to my question have arrived but have ended up in the spam=20
> 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=20
> the 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=20
> is 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=20
> from it, an the initial semaphore as well and unexports the=20
> AmIFirstRemote (to clean up things). Any client that starts up, first=20
> checks whether it finds the InitialSemaphoreExistsEntry in the space.=20
> If so, someone else has inserted the initial semaphore already and=20
> there is no need to export anAmIFirstRemote and all that. If the=20
> inital semaphore doesn't exists in the space, it's only because=20
> 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=20
> a LocateRegistry.getRegistry(rmiPort) or=20
> LocateRegistry.createRegistry(rmiPort) in RMI takes several seconds=20
> and 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=20
> to me...
>
> @Tom: Thanks for your suggestion. To be really honest I only=20
> understand part of it. Might be because I have to little background=20
> knowledge of 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=20
>> is 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=20
>> space). The attribute might be something as simple as "new=20
>> 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=20
>> return 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]=
M>
>> 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=20
>> as a
>> > semaphore. This is what I saw in Freeman's book and that's how I=20
>> intend
>> > to do synchronization. Problem is that someone must be the first=20
>> one to
>> > insert the >single< semaphore entry into the space since it is=20
>> 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 th=
ey
>> > agree on who will do this when an initial semaphore not yet exists i=
n
>> > the space to prevent race conditions from happening when working=20
>> out the
>> > agreement who will be the one?
>> >
>> > As explained I use the RMI registry as a workaround to determine=20
>> who is
>> > the first one (everyone that comes second faces a=20
>> AlreadyExistsException
>> > when binding a remote object to the registry that already exists the=
re
>> > with the same name) and thus is allowed to write the initial semapho=
re
>> > 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=20
>> found
>> > 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=3D454=
18
>> >>
>> >> 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=20
>> in 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=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=20
>> 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)=20
>> and 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=20
>> personal emails. By replying to this email, you consent to Sucden's=20
>> monitoring the content of any emails you send to or receive from=20
>> Sucden. Sucden is not liable for any opinions expressed by the sender=20
>> where this is a non-business email.
>>
>> The contents of this e-mail do not constitute advice and should not=20
>> be regarded as a recommendation to buy, sell or otherwise deal with=20
>> any 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=20
>> the body of the message "signoff JAVASPACES-USERS". For general help,=20
>> send email to [email protected] and include in the body of the=20
>> message "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