Multiple interpreters and data atomicity

[Derek Basch]

Hello All,

I have several servers that share a perl script on a network file
share. This script accesses a telnet server and gets/sets various
attributes.


Server A Server B
| |
---------->script<--------
|
|
v
Data Store/Telnet

Do I need to worry about the atomicity of the attributes in the Data
Store? How does perl handle a situation like this? What if the Data
Store were simply a flat file instead of a Telnet server?

Thanks for the help,
Derek Basch

 

[xhoster]

Hello All,

I have several servers that share a perl script on a network file
share. This script accesses a telnet server and gets/sets various
attributes.

Server A Server B
| |
---------->script<--------
|
|
v
Data Store/Telnet

Do I need to worry about the atomicity of the attributes in the Data
Store? How does perl handle a situation like this? What if the Data
Store were simply a flat file instead of a Telnet server?

I have a piece of string. The piece of string is made out of nylon. How
long is the piece of string?

Based on your description, I see no reason the situation you describe would
be any different than this one:

Server A Server B
| |
script--------\ /---------script
| |
| |
v v
Data Store/Telnet

Xho

 

[Derek Basch]

I have a piece of string. The piece of string is made out of nylon. How

long is the piece of string?

How is this constructive? Have you ever heard the saying "There is no
such thing as a stupid question". I described my problem in detail and
gave exact questions. Questions that you did not answer but instead
mocked me. Why even be on Usenet if you are only going to make people
feel stupid rather than help them?

Based on your description, I see no reason the situation you describe would
be any different than this one:

Server A Server B
| |
script--------\ /---------script
| |
| |
v v
Data Store/Telnet

Xho

Fine, that may be the case. However, you didn't say anything about how
multiple interpreters running on different servers would affect the
atomicity of the data in the Data Store if both interpreters ran the
same function accessing the same attributes in the Data Store at the
same time.

That was my question. Not, "how is this question better expressed". As
far as I can see your example is different because I do not want to
maintain different copies of the same file on multiple servers. So,
theoretically it may be the same but in reality it is not.

I am sorry if this question is beneath you but I googled for a long
time and read all the related Usenet posts I could find and still don't
have an answer. Google for "perl multiple interpreter atomicity" and
you won't find much of anything. Sorry to have wasted your time.

 

[xhoster]

How is this constructive? Have you ever heard the saying "There is no
such thing as a stupid question".

Yes. I happen not to believe it.

I described my problem in detail and
gave exact questions.

No, you didn't. We have no idea what this "Data Store/Telnet" is, nor
how you use Perl to access it. In fact, there was no Perl code at all.
How can you claim to that you gave details in a Perl group when you gave
no Perl code?

Questions that you did not answer but instead
mocked me. Why even be on Usenet if you are only going to make people
feel stupid rather than help them?

I help all kinds of people--ones who ask meaningful questions. I have
little patience of people who act stupid, whether they *feel* stupid or
not.

Fine, that may be the case. However, you didn't say anything about how
multiple interpreters running on different servers would affect the
atomicity of the data in the Data Store if both interpreters ran the
same function accessing the same attributes in the Data Store at the
same time.

That is an issue to take up with this mysterious Data Store.

That was my question. Not, "how is this question better expressed". As
far as I can see your example is different because I do not want to
maintain different copies of the same file on multiple servers. So,
theoretically it may be the same but in reality it is not.

If the two situations were different, then there might be some Perl content
to your question. If (as I proposed as being most likely) the two
situations are not different, then there is no Perl content in your
question. It is completely a matter of what this "Data Store" is and
exactly what level/type of atomicity is required.

I am sorry if this question is beneath you but I googled for a long
time and read all the related Usenet posts I could find and still don't
have an answer. Google for "perl multiple interpreter atomicity" and
you won't find much of anything. Sorry to have wasted your time.

That is because you are barking up the wrong tree. Atomicity is primarily
a property of the "Data Store" server, not the Perl (or Java, or Python,
or C++, or Lisp, or Small Talk, or Ruby, or ...) client which talks to it.
I thought that claiming the equivalence of your original diagram to my
re-arranged one would have made this obvious.

Xho

 

[Keith Keller]

How is this constructive? Have you ever heard the saying "There is no
such thing as a stupid question". I described my problem in detail and
gave exact questions.

You did not describe your problem in detail. Whether that's because
you do not know all the details, or simply neglected to include them,
we have no way of knowing.

The answers to your ''exact'' questions depend greatly on the exact
nature of your script and your data store. So, your aphorism might be
rephrased "There are no stupid questions, but there are foolish ways
of asking."

Fine, that may be the case. However, you didn't say anything about how
multiple interpreters running on different servers would affect the
atomicity of the data in the Data Store if both interpreters ran the
same function accessing the same attributes in the Data Store at the
same time.

It depends on the data store. If the data store is a Perl program,
then your question is entirely appropriate here, but you need to
provide more specifics. If it's not Perl, then you might try a
different newsgroup/mailing list dedicated to that product, asking
how it handles your scenario; if they say "it is all handled by the
client" then you might ask back here with that information. (Though
in that case, it seems likely the answer to your question is obvious.)

The bottom line: it depends on the data store!

--keith

 

[Tad McClellan]

How is this constructive?

By pointing out that there is no way to answer the question
with only the given information.

I described my problem in detail and

^^^^^^^^^

There was no Perl code.

gave exact questions. Questions that you did not answer

There is no obligation for followups to answer any question you know.

Why even be on Usenet if you are only going to make people
feel stupid rather than help them?

^^^^^^^^^^^

Feeling stupid and being helped are not mutually exclusive,
(it happens to me with distressing frequency).

It _is_ helpful to know that you are looking in the wrong place
for the solution to your problem.

Fine, that may be the case. However, you didn't say anything about how
multiple interpreters running on different servers would affect the
atomicity of the data in the Data Store if both interpreters ran the
same function accessing the same attributes in the Data Store at the
same time.

Because that is not a programming language question.

That is a Data Store question. The DB would have to also handle
the situation of two _different_ programs accessing the same
attributes in the Data Store at the same time.

The fact that the 2 processes are running the same source code has
no effect on whatever facilities the Data Store has for dealing
with concurrent access.

As
far as I can see your example is different because I do not want to
maintain different copies of the same file on multiple servers.

Xho's example does not require different copies of the same file
on multiple servers.

What makes you think that it does?


Xho's example does require different _processes_ executing on multiple
servers though.

What matters are processes, they are the only way code gets executed.

Files are just a convenient, and often used, way of supplying some
code to the process for execution.

So,
theoretically it may be the same but in reality it is not.

So in reality it _is_ the same.

You have multiple processes either way.

I am sorry if this question is beneath you but I googled for a long
time and read all the related Usenet posts I could find and still don't
have an answer. Google for "perl multiple interpreter atomicity" and
you won't find much of anything.

Because multiple perl interpreters have no effect on atomicity.

Sorry to have wasted your time.

No you're not.

 

[Derek Basch]

No, you didn't. We have no idea what this "Data Store/Telnet" is, nor

how you use Perl to access it. In fact, there was no Perl code at all.

I thought this paragraph covered everything:

I have several servers that share a perl script on a network file
share. This script accesses a telnet server and gets/sets various
attributes.

Apparently not. I apologize. I realize now I should have given more
detail about what the Data Store is. I thought I had explained enough
but I am not perfect and make mistakes.

I help all kinds of people--ones who ask meaningful questions. I have
little patience of people who act stupid, whether they *feel* stupid or
not.

What I don't understand is if someones slightly less than complete
question bugs you why even bother responding in a negative fashion? Why
not just say "You didn't expand upon xyz enough for me to answer your
question. Could you please restate your question with more detail on
xyz?". How does mocking me help anyone?

How can you claim to that you gave details in a Perl group when you gave
no Perl code?

I didn't think it was necessary to show something as basic as how to
write to a Telnet socket in perl. Apparently not. I apologize.

That is because you are barking up the wrong tree. Atomicity is primarily
a property of the "Data Store" server, not the Perl (or Java, or Python,
or C++, or Lisp, or Small Talk, or Ruby, or ...) client which talks to it.
I thought that claiming the equivalence of your original diagram to my
re-arranged one would have made this obvious.

I realize this now that you and others have explained it to me. Every
ones explanations of the difference between files and processes was
very helpful and answered my question.

I suppose I could not find any information on multiple processes
accessing the same code block because it really was a "stupid"
question. However, I don't understand how I would have ever learned any
of this if I had never asked my "stupid" question?

I REALLY am sorry to have wasted every ones time and will do my best to
explain myself in fuller detail from now on. I apologize for being
short but I guess I get easily angered by people who mock others who
make simple mistakes. Thank you for taking the time to answer my
question. I will move my query to a socket or telnet mailing list.

 

[Peter J. Holzer]

I apologize for being short but I guess I get easily angered by people
who mock others who make simple mistakes.

Get used to it. This is usenet. Some people will answer the question you
asked. Some will answer the question they think you should have asked.
Some will ask counter questions. Some will discuss a completely
irrelevant detail of your posting at great length. Some will be polite.
Some won't. Some know what they are talking about and some don't. Some
can express themselves well, and some can't.

hp

 

[Keith Keller]

Apparently not. I apologize. I realize now I should have given more
detail about what the Data Store is. I thought I had explained enough
but I am not perfect and make mistakes.

You say this, but...

I will move my query to a socket or telnet mailing list.

then you say this, which seems to indicate that you really don't
understand the issue. The socket is not relevant; telnet is not
relevant. The *data store* is the important piece of your question:
what does it do when it gets data from multiple clients? If you can't
answer that question (or find someone who can), there's no way anyone
will be able to help you with any client issues.

--keith