Loading ...
Sorry, an error occurred while loading the content.
 

Re: [soaplite] variable persistance on server process

Expand Messages
  • Dirk Eddelbuettel
    ... Using a standard SOAP server with dynamic dispatch as per Paul s (excellent and numerous) examples, the client request an module in which I wrapped DBI
    Message 1 of 10 , May 17, 2001
      > I have written a SOAP::Lite server that opens a database connection
      > upon startup (ie before handle() is called).
      >
      > I need to find away to make this handle (variable) availiable to
      > all/any dispatched packages. The variable is persistant througout
      > the servers duration and so over multiple SOAP requests.

      Using a standard SOAP server with dynamic dispatch as per Paul's
      (excellent and numerous) examples, the client request an 'module'
      in which I wrapped DBI calls. The db connection is opened at startup
      and maintained as long as the server is running. I do not "pass" the db
      handle out to the client as the client requests data from the SOAP
      server, and not directly from the database.

      Hth, Dirk

      --
      According to the latest figures, 43% of all signatures are totally worthless.
    • rog2@foskett.f9.co.uk
      ... thanks, So you open the connection in a BEGIN block in a dispatched package? When I tried, BEGIN or any other class variables are destroyed when the client
      Message 2 of 10 , May 17, 2001
        > Using a standard SOAP server with dynamic dispatch as per Paul's
        > (excellent and numerous) examples, the client request an 'module'
        > in which I wrapped DBI calls. The db connection is opened at
        > startup and maintained as long as the server is running. I do
        > not "pass" the db handle out to the client as the client
        > requests data from the SOAP server, and not directly from the
        > database.

        thanks,

        So you open the connection in a BEGIN block in a dispatched package?
        When I tried, BEGIN or any other class variables are destroyed when
        the client request finishes (even though the server process is still
        running). BEGIN is also invoked for every client request.

        Also, where is the disconnect performed?

        could you perhaps point me to any examples that might illustrate this?

        thanks very much

        roger foskett
      • Paul Kulchenko
        Hi, Roger! This question brings us two subquestions: 1. How to keep data persistent inside one process a. inside one module? b. between modules? 2. How to keep
        Message 3 of 10 , May 17, 2001
          Hi, Roger!

          This question brings us two subquestions:
          1. How to keep data persistent inside one process
          a. inside one module?
          b. between modules?
          2. How to keep data persistent between processes

          Answer for 1.a is in examples/My/PersistentIterator.pm

          You just need to create class variable ($iterator) in this example
          that will store object or something else you need to keep, and Perl's
          GC will not release this variable, so on handling next request you
          can recover it and use.

          1.b require similar technique, but between classes. Create class that
          will have one class method (getHandler) that will work something
          like:

          package PersistentHandler;

          my $handler;

          sub getHandler {
          $handler ||= initHandler();
          }

          sub initHandler {

          }

          Every package that want to access this handler will call
          PersistentHandler->getHandler, so on the very first call it'll be
          initialized and then reused. As soon as $handler keeps that reference
          there is NO WAY to release it automatically, so there either should
          be method that will release it manually, or some logic that will
          check for validity of that handler and reopen it.

          2. is similar to 1.b, but there is no way to share data unless you
          have multithreaded environment (instead of forked). If you DO
          multithreads, then you can follow 1.b advice. If you DO fork, you
          need to use some persistent techniques and SOAP::Lite won't help you
          here. I plan to add interface similar to Apache::Sessions, so you'll
          be able to keep data in external storage, like file, database or
          shared memory, but for now you're on your own.

          Best wishes, Paul.

          --- rog2@... wrote:
          >
          > > Using a standard SOAP server with dynamic dispatch as per Paul's
          > > (excellent and numerous) examples, the client request an 'module'
          > > in which I wrapped DBI calls. The db connection is opened at
          > > startup and maintained as long as the server is running. I do
          > > not "pass" the db handle out to the client as the client
          > > requests data from the SOAP server, and not directly from the
          > > database.
          >
          > thanks,
          >
          > So you open the connection in a BEGIN block in a dispatched
          > package?
          > When I tried, BEGIN or any other class variables are destroyed when
          >
          > the client request finishes (even though the server process is
          > still
          > running). BEGIN is also invoked for every client request.
          >
          > Also, where is the disconnect performed?
          >
          > could you perhaps point me to any examples that might illustrate
          > this?
          >
          > thanks very much
          >
          > roger foskett
          >
          >
          >
          > To unsubscribe from this group, send an email to:
          > soaplite-unsubscribe@yahoogroups.com
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Yahoo! Auctions - buy the things you want at great prices
          http://auctions.yahoo.com/
        • Meisner, Sean
          Hi Roger, You *should* be able to access your open database handle from packages, if you open it in the mainline of the server before calling handle, and fully
          Message 4 of 10 , May 17, 2001
            Hi Roger,

            You *should* be able to access your open database handle
            from packages, if you open it in the mainline of the
            server before calling handle, and fully qualify it when
            using it in the packages..
            i.e.

            ########## main

            my $dbh = DBI->...

            ...

            $daemon->handle;

            $dbh->disconnect();

            ########## End main

            ##### package

            if (defined $main::dbh)
            {
            $main::dbh->...
            }
            else
            {
            die "database connection not found";
            }

            #### end package

            Hope that helps, but bear in mind that I haven't used
            dynamic dispatch myself, so it may not be this simple..

            Cheers,

            Sean

            -----Original Message-----
            From: rog2@... [mailto:rog2@...]
            Sent: Thursday, May 17, 2001 10:44 AM
            To: soaplite@yahoogroups.com
            Subject: [soaplite] Re: variable persistance on server process



            > Using a standard SOAP server with dynamic dispatch as per Paul's
            > (excellent and numerous) examples, the client request an 'module'
            > in which I wrapped DBI calls. The db connection is opened at
            > startup and maintained as long as the server is running. I do
            > not "pass" the db handle out to the client as the client
            > requests data from the SOAP server, and not directly from the
            > database.

            thanks,

            So you open the connection in a BEGIN block in a dispatched package?
            When I tried, BEGIN or any other class variables are destroyed when
            the client request finishes (even though the server process is still
            running). BEGIN is also invoked for every client request.

            Also, where is the disconnect performed?

            could you perhaps point me to any examples that might illustrate this?

            thanks very much

            roger foskett



            To unsubscribe from this group, send an email to:
            soaplite-unsubscribe@yahoogroups.com



            Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          • Arun Kumar U
            ... Classic case for a Singleton Pattern, correct me if I am wrong. So, why not use Class::Singleton ? Have Class::Singleton as the base class for the class
            Message 5 of 10 , May 17, 2001
              > 1.b require similar technique, but between classes. Create class that
              > will have one class method (getHandler) that will work something
              > like:
              >
              > package PersistentHandler;
              >
              > my $handler;
              >
              > sub getHandler {
              > $handler ||= initHandler();
              > }
              >
              > sub initHandler {
              >
              > }

              Classic case for a Singleton Pattern, correct me if I am wrong.
              So, why not use Class::Singleton ? Have Class::Singleton as the
              base class for the class that you want to share between modules.

              Best Regards,
              Arun


              On Thu, 17 May 2001, Paul Kulchenko wrote:

              > Hi, Roger!
              >
              > This question brings us two subquestions:
              > 1. How to keep data persistent inside one process
              > a. inside one module?
              > b. between modules?
              > 2. How to keep data persistent between processes
              >
              > Answer for 1.a is in examples/My/PersistentIterator.pm
              >
              > You just need to create class variable ($iterator) in this example
              > that will store object or something else you need to keep, and Perl's
              > GC will not release this variable, so on handling next request you
              > can recover it and use.
              >
              > 1.b require similar technique, but between classes. Create class that
              > will have one class method (getHandler) that will work something
              > like:
              >
              > package PersistentHandler;
              >
              > my $handler;
              >
              > sub getHandler {
              > $handler ||= initHandler();
              > }
              >
              > sub initHandler {
              >
              > }
              >
              >
              > Every package that want to access this handler will call
              > PersistentHandler->getHandler, so on the very first call it'll be
              > initialized and then reused. As soon as $handler keeps that reference
              > there is NO WAY to release it automatically, so there either should
              > be method that will release it manually, or some logic that will
              > check for validity of that handler and reopen it.
              >
              > 2. is similar to 1.b, but there is no way to share data unless you
              > have multithreaded environment (instead of forked). If you DO
              > multithreads, then you can follow 1.b advice. If you DO fork, you
              > need to use some persistent techniques and SOAP::Lite won't help you
              > here. I plan to add interface similar to Apache::Sessions, so you'll
              > be able to keep data in external storage, like file, database or
              > shared memory, but for now you're on your own.
              >
              > Best wishes, Paul.
              >
              > --- rog2@... wrote:
              > >
              > > > Using a standard SOAP server with dynamic dispatch as per Paul's
              > > > (excellent and numerous) examples, the client request an 'module'
              > > > in which I wrapped DBI calls. The db connection is opened at
              > > > startup and maintained as long as the server is running. I do
              > > > not "pass" the db handle out to the client as the client
              > > > requests data from the SOAP server, and not directly from the
              > > > database.
              > >
              > > thanks,
              > >
              > > So you open the connection in a BEGIN block in a dispatched
              > > package?
              > > When I tried, BEGIN or any other class variables are destroyed when
              > >
              > > the client request finishes (even though the server process is
              > > still
              > > running). BEGIN is also invoked for every client request.
              > >
              > > Also, where is the disconnect performed?
              > >
              > > could you perhaps point me to any examples that might illustrate
              > > this?
              > >
              > > thanks very much
              > >
              > > roger foskett
              > >
              > >
              > >
              > > To unsubscribe from this group, send an email to:
              > > soaplite-unsubscribe@yahoogroups.com
              > >
              > >
              > >
              > > Your use of Yahoo! Groups is subject to
              > > http://docs.yahoo.com/info/terms/
              > >
              > >
              >
              >
              > __________________________________________________
              > Do You Yahoo!?
              > Yahoo! Auctions - buy the things you want at great prices
              > http://auctions.yahoo.com/
              >
            • Paul Kulchenko
              Hi, Arun! ... Sounds like a good idea to me. You not always can alter inheritance in your classes, but if you can, definitely this approach can be used. Even
              Message 6 of 10 , May 17, 2001
                Hi, Arun!

                > Classic case for a Singleton Pattern, correct me if I am wrong.
                > So, why not use Class::Singleton ? Have Class::Singleton as the
                > base class for the class that you want to share between modules.
                Sounds like a good idea to me. You not always can alter inheritance
                in your classes, but if you can, definitely this approach can be
                used. Even if you can't, you can do it in non-OO fasion:

                use Class::Singleton;
                Class::Singleton->instance();

                Thanks for the hint, Arun!

                Best wishes, Paul.

                --- Arun Kumar U <u_arunkumar@...> wrote:
                >
                > > 1.b require similar technique, but between classes. Create class
                > that
                > > will have one class method (getHandler) that will work something
                > > like:
                > >
                > > package PersistentHandler;
                > >
                > > my $handler;
                > >
                > > sub getHandler {
                > > $handler ||= initHandler();
                > > }
                > >
                > > sub initHandler {
                > >
                > > }
                >
                > Classic case for a Singleton Pattern, correct me if I am wrong.
                > So, why not use Class::Singleton ? Have Class::Singleton as the
                > base class for the class that you want to share between modules.
                >
                > Best Regards,
                > Arun
                >
                >
                > On Thu, 17 May 2001, Paul Kulchenko wrote:
                >
                > > Hi, Roger!
                > >
                > > This question brings us two subquestions:
                > > 1. How to keep data persistent inside one process
                > > a. inside one module?
                > > b. between modules?
                > > 2. How to keep data persistent between processes
                > >
                > > Answer for 1.a is in examples/My/PersistentIterator.pm
                > >
                > > You just need to create class variable ($iterator) in this
                > example
                > > that will store object or something else you need to keep, and
                > Perl's
                > > GC will not release this variable, so on handling next request
                > you
                > > can recover it and use.
                > >
                > > 1.b require similar technique, but between classes. Create class
                > that
                > > will have one class method (getHandler) that will work something
                > > like:
                > >
                > > package PersistentHandler;
                > >
                > > my $handler;
                > >
                > > sub getHandler {
                > > $handler ||= initHandler();
                > > }
                > >
                > > sub initHandler {
                > >
                > > }
                > >
                > >
                > > Every package that want to access this handler will call
                > > PersistentHandler->getHandler, so on the very first call it'll be
                > > initialized and then reused. As soon as $handler keeps that
                > reference
                > > there is NO WAY to release it automatically, so there either
                > should
                > > be method that will release it manually, or some logic that will
                > > check for validity of that handler and reopen it.
                > >
                > > 2. is similar to 1.b, but there is no way to share data unless
                > you
                > > have multithreaded environment (instead of forked). If you DO
                > > multithreads, then you can follow 1.b advice. If you DO fork, you
                > > need to use some persistent techniques and SOAP::Lite won't help
                > you
                > > here. I plan to add interface similar to Apache::Sessions, so
                > you'll
                > > be able to keep data in external storage, like file, database or
                > > shared memory, but for now you're on your own.
                > >
                > > Best wishes, Paul.
                > >
                > > --- rog2@... wrote:
                > > >
                > > > > Using a standard SOAP server with dynamic dispatch as per
                > Paul's
                > > > > (excellent and numerous) examples, the client request an
                > 'module'
                > > > > in which I wrapped DBI calls. The db connection is opened at
                > > > > startup and maintained as long as the server is running. I do
                > > > > not "pass" the db handle out to the client as the client
                > > > > requests data from the SOAP server, and not directly from the
                > > > > database.
                > > >
                > > > thanks,
                > > >
                > > > So you open the connection in a BEGIN block in a dispatched
                > > > package?
                > > > When I tried, BEGIN or any other class variables are destroyed
                > when
                > > >
                > > > the client request finishes (even though the server process is
                > > > still
                > > > running). BEGIN is also invoked for every client request.
                > > >
                > > > Also, where is the disconnect performed?
                > > >
                > > > could you perhaps point me to any examples that might
                > illustrate
                > > > this?
                > > >
                > > > thanks very much
                > > >
                > > > roger foskett
                > > >
                > > >
                > > >
                > > > To unsubscribe from this group, send an email to:
                > > > soaplite-unsubscribe@yahoogroups.com
                > > >
                > > >
                > > >
                > > > Your use of Yahoo! Groups is subject to
                > > > http://docs.yahoo.com/info/terms/
                > > >
                > > >
                > >
                > >
                > > __________________________________________________
                > > Do You Yahoo!?
                > > Yahoo! Auctions - buy the things you want at great prices
                > > http://auctions.yahoo.com/
                > >
                >
                >
                > To unsubscribe from this group, send an email to:
                > soaplite-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                >
                >


                __________________________________________________
                Do You Yahoo!?
                Yahoo! Auctions - buy the things you want at great prices
                http://auctions.yahoo.com/
              • rog2@foskett.f9.co.uk
                ... Great - thanks Paul! that will do the trick (dont know why I didnt get it working before) Roger
                Message 7 of 10 , May 17, 2001
                  > package PersistentHandler;
                  > my $handler;
                  > sub getHandler {
                  > $handler ||= initHandler();
                  > }
                  > sub initHandler {
                  > }

                  Great - thanks Paul!

                  that will do the trick (dont know why I didnt get it working before)

                  Roger
                • Arun Kumar U
                  Hi Paul, ... How about registering this idea as an example or better still document it in the cookbook ? I think it would be helpful to everyother SOAP::Lite
                  Message 8 of 10 , May 17, 2001
                    Hi Paul,

                    > Sounds like a good idea to me. You not always can alter inheritance
                    > in your classes, but if you can, definitely this approach can be
                    > used. Even if you can't, you can do it in non-OO fasion:
                    >
                    > use Class::Singleton;
                    > Class::Singleton->instance();
                    >
                    > Thanks for the hint, Arun!

                    How about registering this idea as an example or better still document
                    it in the cookbook ? I think it would be helpful to everyother SOAP::Lite
                    newbie, dealing with stuff like this.

                    Best Regards,
                    Arun

                    On Thu, 17 May 2001, Paul Kulchenko wrote:

                    > Hi, Arun!
                    >
                    > > Classic case for a Singleton Pattern, correct me if I am wrong.
                    > > So, why not use Class::Singleton ? Have Class::Singleton as the
                    > > base class for the class that you want to share between modules.
                    > Sounds like a good idea to me. You not always can alter inheritance
                    > in your classes, but if you can, definitely this approach can be
                    > used. Even if you can't, you can do it in non-OO fasion:
                    >
                    > use Class::Singleton;
                    > Class::Singleton->instance();
                    >
                    > Thanks for the hint, Arun!
                    >
                    > Best wishes, Paul.
                    >
                    > --- Arun Kumar U <u_arunkumar@...> wrote:
                    > >
                    > > > 1.b require similar technique, but between classes. Create class
                    > > that
                    > > > will have one class method (getHandler) that will work something
                    > > > like:
                    > > >
                    > > > package PersistentHandler;
                    > > >
                    > > > my $handler;
                    > > >
                    > > > sub getHandler {
                    > > > $handler ||= initHandler();
                    > > > }
                    > > >
                    > > > sub initHandler {
                    > > >
                    > > > }
                    > >
                    > > Classic case for a Singleton Pattern, correct me if I am wrong.
                    > > So, why not use Class::Singleton ? Have Class::Singleton as the
                    > > base class for the class that you want to share between modules.
                    > >
                    > > Best Regards,
                    > > Arun
                    > >
                    > >
                    > > On Thu, 17 May 2001, Paul Kulchenko wrote:
                    > >
                    > > > Hi, Roger!
                    > > >
                    > > > This question brings us two subquestions:
                    > > > 1. How to keep data persistent inside one process
                    > > > a. inside one module?
                    > > > b. between modules?
                    > > > 2. How to keep data persistent between processes
                    > > >
                    > > > Answer for 1.a is in examples/My/PersistentIterator.pm
                    > > >
                    > > > You just need to create class variable ($iterator) in this
                    > > example
                    > > > that will store object or something else you need to keep, and
                    > > Perl's
                    > > > GC will not release this variable, so on handling next request
                    > > you
                    > > > can recover it and use.
                    > > >
                    > > > 1.b require similar technique, but between classes. Create class
                    > > that
                    > > > will have one class method (getHandler) that will work something
                    > > > like:
                    > > >
                    > > > package PersistentHandler;
                    > > >
                    > > > my $handler;
                    > > >
                    > > > sub getHandler {
                    > > > $handler ||= initHandler();
                    > > > }
                    > > >
                    > > > sub initHandler {
                    > > >
                    > > > }
                    > > >
                    > > >
                    > > > Every package that want to access this handler will call
                    > > > PersistentHandler->getHandler, so on the very first call it'll be
                    > > > initialized and then reused. As soon as $handler keeps that
                    > > reference
                    > > > there is NO WAY to release it automatically, so there either
                    > > should
                    > > > be method that will release it manually, or some logic that will
                    > > > check for validity of that handler and reopen it.
                    > > >
                    > > > 2. is similar to 1.b, but there is no way to share data unless
                    > > you
                    > > > have multithreaded environment (instead of forked). If you DO
                    > > > multithreads, then you can follow 1.b advice. If you DO fork, you
                    > > > need to use some persistent techniques and SOAP::Lite won't help
                    > > you
                    > > > here. I plan to add interface similar to Apache::Sessions, so
                    > > you'll
                    > > > be able to keep data in external storage, like file, database or
                    > > > shared memory, but for now you're on your own.
                    > > >
                    > > > Best wishes, Paul.
                    > > >
                    > > > --- rog2@... wrote:
                    > > > >
                    > > > > > Using a standard SOAP server with dynamic dispatch as per
                    > > Paul's
                    > > > > > (excellent and numerous) examples, the client request an
                    > > 'module'
                    > > > > > in which I wrapped DBI calls. The db connection is opened at
                    > > > > > startup and maintained as long as the server is running. I do
                    > > > > > not "pass" the db handle out to the client as the client
                    > > > > > requests data from the SOAP server, and not directly from the
                    > > > > > database.
                    > > > >
                    > > > > thanks,
                    > > > >
                    > > > > So you open the connection in a BEGIN block in a dispatched
                    > > > > package?
                    > > > > When I tried, BEGIN or any other class variables are destroyed
                    > > when
                    > > > >
                    > > > > the client request finishes (even though the server process is
                    > > > > still
                    > > > > running). BEGIN is also invoked for every client request.
                    > > > >
                    > > > > Also, where is the disconnect performed?
                    > > > >
                    > > > > could you perhaps point me to any examples that might
                    > > illustrate
                    > > > > this?
                    > > > >
                    > > > > thanks very much
                    > > > >
                    > > > > roger foskett
                    > > > >
                    > > > >
                    > > > >
                    > > > > To unsubscribe from this group, send an email to:
                    > > > > soaplite-unsubscribe@yahoogroups.com
                    > > > >
                    > > > >
                    > > > >
                    > > > > Your use of Yahoo! Groups is subject to
                    > > > > http://docs.yahoo.com/info/terms/
                    > > > >
                    > > > >
                    > > >
                    > > >
                    > > > __________________________________________________
                    > > > Do You Yahoo!?
                    > > > Yahoo! Auctions - buy the things you want at great prices
                    > > > http://auctions.yahoo.com/
                    > > >
                    > >
                    > >
                    > > To unsubscribe from this group, send an email to:
                    > > soaplite-unsubscribe@yahoogroups.com
                    > >
                    > >
                    > >
                    > > Your use of Yahoo! Groups is subject to
                    > > http://docs.yahoo.com/info/terms/
                    > >
                    > >
                    >
                    >
                    > __________________________________________________
                    > Do You Yahoo!?
                    > Yahoo! Auctions - buy the things you want at great prices
                    > http://auctions.yahoo.com/
                    >
                  • Paul Kulchenko
                    Hi, Arun! Done deal. I ve added five more questions today and this one is on the way. Best wishes, Paul. ... === message truncated ===
                    Message 9 of 10 , May 17, 2001
                      Hi, Arun!

                      Done deal. I've added five more questions today and this one is on
                      the way.

                      Best wishes, Paul.

                      --- Arun Kumar U <u_arunkumar@...> wrote:
                      >
                      > Hi Paul,
                      >
                      > > Sounds like a good idea to me. You not always can alter
                      > inheritance
                      > > in your classes, but if you can, definitely this approach can be
                      > > used. Even if you can't, you can do it in non-OO fasion:
                      > >
                      > > use Class::Singleton;
                      > > Class::Singleton->instance();
                      > >
                      > > Thanks for the hint, Arun!
                      >
                      > How about registering this idea as an example or better still
                      > document
                      > it in the cookbook ? I think it would be helpful to everyother
                      > SOAP::Lite
                      > newbie, dealing with stuff like this.
                      >
                      > Best Regards,
                      > Arun
                      >
                      > On Thu, 17 May 2001, Paul Kulchenko wrote:
                      >
                      > > Hi, Arun!
                      > >
                      > > > Classic case for a Singleton Pattern, correct me if I am wrong.
                      > > > So, why not use Class::Singleton ? Have Class::Singleton as the
                      > > > base class for the class that you want to share between
                      > modules.
                      > > Sounds like a good idea to me. You not always can alter
                      > inheritance
                      > > in your classes, but if you can, definitely this approach can be
                      > > used. Even if you can't, you can do it in non-OO fasion:
                      > >
                      > > use Class::Singleton;
                      > > Class::Singleton->instance();
                      > >
                      > > Thanks for the hint, Arun!
                      > >
                      > > Best wishes, Paul.
                      > >
                      > > --- Arun Kumar U <u_arunkumar@...> wrote:
                      > > >
                      > > > > 1.b require similar technique, but between classes. Create
                      > class
                      > > > that
                      > > > > will have one class method (getHandler) that will work
                      > something
                      > > > > like:
                      > > > >
                      > > > > package PersistentHandler;
                      > > > >
                      > > > > my $handler;
                      > > > >
                      > > > > sub getHandler {
                      > > > > $handler ||= initHandler();
                      > > > > }
                      > > > >
                      > > > > sub initHandler {
                      > > > >
                      > > > > }
                      > > >
                      > > > Classic case for a Singleton Pattern, correct me if I am wrong.
                      > > > So, why not use Class::Singleton ? Have Class::Singleton as the
                      > > > base class for the class that you want to share between
                      > modules.
                      > > >
                      > > > Best Regards,
                      > > > Arun
                      > > >
                      > > >
                      > > > On Thu, 17 May 2001, Paul Kulchenko wrote:
                      > > >
                      > > > > Hi, Roger!
                      > > > >
                      > > > > This question brings us two subquestions:
                      > > > > 1. How to keep data persistent inside one process
                      > > > > a. inside one module?
                      > > > > b. between modules?
                      > > > > 2. How to keep data persistent between processes
                      > > > >
                      > > > > Answer for 1.a is in examples/My/PersistentIterator.pm
                      > > > >
                      > > > > You just need to create class variable ($iterator) in this
                      > > > example
                      > > > > that will store object or something else you need to keep,
                      > and
                      > > > Perl's
                      > > > > GC will not release this variable, so on handling next
                      > request
                      > > > you
                      > > > > can recover it and use.
                      > > > >
                      > > > > 1.b require similar technique, but between classes. Create
                      > class
                      > > > that
                      > > > > will have one class method (getHandler) that will work
                      > something
                      > > > > like:
                      > > > >
                      > > > > package PersistentHandler;
                      > > > >
                      > > > > my $handler;
                      > > > >
                      > > > > sub getHandler {
                      > > > > $handler ||= initHandler();
                      > > > > }
                      > > > >
                      > > > > sub initHandler {
                      > > > >
                      > > > > }
                      > > > >
                      > > > >
                      > > > > Every package that want to access this handler will call
                      > > > > PersistentHandler->getHandler, so on the very first call
                      > it'll be
                      > > > > initialized and then reused. As soon as $handler keeps that
                      > > > reference
                      > > > > there is NO WAY to release it automatically, so there either
                      > > > should
                      > > > > be method that will release it manually, or some logic that
                      > will
                      > > > > check for validity of that handler and reopen it.
                      > > > >
                      > > > > 2. is similar to 1.b, but there is no way to share data
                      > unless
                      > > > you
                      > > > > have multithreaded environment (instead of forked). If you DO
                      > > > > multithreads, then you can follow 1.b advice. If you DO fork,
                      > you
                      > > > > need to use some persistent techniques and SOAP::Lite won't
                      > help
                      > > > you
                      > > > > here. I plan to add interface similar to Apache::Sessions, so
                      > > > you'll
                      > > > > be able to keep data in external storage, like file, database
                      > or
                      > > > > shared memory, but for now you're on your own.
                      > > > >
                      > > > > Best wishes, Paul.
                      > > > >
                      > > > > --- rog2@... wrote:
                      > > > > >
                      > > > > > > Using a standard SOAP server with dynamic dispatch as per
                      > > > Paul's
                      > > > > > > (excellent and numerous) examples, the client request an
                      > > > 'module'
                      > > > > > > in which I wrapped DBI calls. The db connection is
                      > opened at
                      > > > > > > startup and maintained as long as the server is running.
                      > I do
                      > > > > > > not "pass" the db handle out to the client as the client
                      > > > > > > requests data from the SOAP server, and not directly from
                      > the
                      > > > > > > database.
                      > > > > >
                      > > > > > thanks,
                      > > > > >
                      > > > > > So you open the connection in a BEGIN block in a dispatched
                      > > > > > package?
                      > > > > > When I tried, BEGIN or any other class variables are
                      > destroyed
                      > > > when
                      > > > > >
                      > > > > > the client request finishes (even though the server process
                      > is
                      > > > > > still
                      > > > > > running). BEGIN is also invoked for every client request.
                      > > > > >
                      > > > > > Also, where is the disconnect performed?
                      > > > > >
                      > > > > > could you perhaps point me to any examples that might
                      > > > illustrate
                      > > > > > this?
                      > > > > >
                      > > > > > thanks very much
                      > > > > >
                      > > > > > roger foskett
                      > > > > >
                      > > > > >
                      > > > > >
                      > > > > > To unsubscribe from this group, send an email to:
                      > > > > > soaplite-unsubscribe@yahoogroups.com
                      > > > > >
                      > > > > >
                      > > > > >
                      > > > > > Your use of Yahoo! Groups is subject to
                      > > > > > http://docs.yahoo.com/info/terms/
                      > > > > >
                      > > > > >
                      > > > >
                      > > > >
                      > > > > __________________________________________________
                      > > > > Do You Yahoo!?
                      > > > > Yahoo! Auctions - buy the things you want at great prices
                      > > > > http://auctions.yahoo.com/
                      > > > >
                      > > >
                      > > >
                      > > > To unsubscribe from this group, send an email to:
                      >
                      === message truncated ===


                      __________________________________________________
                      Do You Yahoo!?
                      Yahoo! Auctions - buy the things you want at great prices
                      http://auctions.yahoo.com/
                    Your message has been successfully submitted and would be delivered to recipients shortly.