SoapServer::setPersistence

(PHP 5, PHP 7, PHP 8)

SoapServer::setPersistence — Establece el modo de persistencia de SoapServer

Descripción

public SoapServer::setPersistence(int $mode): void

Esta función permite cambiar el estado de persistencia de un objeto SoapServer entre peticiones. Esta función permite guardar datos entre peticiones usando sesiones de PHP. Este método solamente tiene efecto en un SoapServer después de exportar funciones utilizando SoapServer::setClass().

Nota:
La persistencia de SOAP_PERSISTENCE_SESSION solamente hace persistentes a los objetos de la clase dad, no los datos estáticos de la clase. En este caso, use $this->bar en lugar de self::$bar.

Nota:
SOAP_PERSISTENCE_SESSION serializa datos en el objeto de clase entre peticiones. Para poder adecuadamente utilizar recursos (p.ej. PDO), deberían usarse los métodos mágicos __wakeup() y __sleep().

Parámetros

mode

Una de las constantes SOAP_PERSISTENCE_XXX.

SOAP_PERSISTENCE_REQUEST - Los datos de SoapServer no persisten entre peticiones. Este es el comportamiento predeterminado de cualquier objeto SoapServer después de llamar a setClass.

SOAP_PERSISTENCE_SESSION - Los datos de SoapServer persisten entre peticiones. Esto se lleva a cabo serializando los datos de la clase SoapServer en $_SESSION['_nombre_sesión_falso'], ya que session_start() debe invocarse antes de establecer este modo de persistencia.

Valores devueltos

No devuelve ningún valor.

Ejemplos

Ejemplo #1 Ejemplo de SoapServer::setPersistence()

<?php
 class MyFirstPersistentSoapServer {
     private $resource; // (Tal como PDO, mysqli, etc..)
     public $mivar1;
     public $mivar2;

     public function __construct() {
         $this->__wakeup(); // Estamos llamando nuestro wakeup para manejar nuestro recurso
     }

     public function __wakeup() {
         $this->resource = CodeToStartOurResourceUp();
     }

     public function __sleep() {
         // Nos aseguramos de omitir $resource aquí, por lo que nuestro datos de sesión persisten
         // Un fallo resultará en el fallo durante la deserialilzación de datos
         // en la próxima petición; por lo tanto, nuestro SoapObject no sería persistente entre peticiones.
         return array('mivar1','mivar2');
     }
 }

 try {
     session_start();
     $server = new SoapServer(null, array('uri' => $_SERVER['REQUEST_URI']));
     $server->setClass('MyFirstPersistentSoapServer');
     // setPersistence DEBE invocarse después de setClass, debido a que el comportamiento
     // de setClass establece SESSION_PERSISTENCE_REQUEST tras promulgar el método.
     $server->setPersistence(SOAP_PERSISTENCE_SESSION);
     $server->handle();
 } catch(SoapFault $e) {
     error_log("SOAP ERROR: ". $e->getMessage());
 }
?>

Ver también

SoapServer::setClass() - Define la clase que controla las peticiones SOAP

Found A Problem?

Learn How To Improve This Page • Submit a Pull Request • Report a Bug

＋add a note

User Contributed Notes 6 notes

down

csnaitsirch at web dot de ¶

14 years ago

I want to give one example for the order of commands if you want to use a class in persistence mode.

<?php
// 1. class definition or include
class UserService
{
    public function __construct() { }
}

// 2. start the session after defining or including the class!!
session_start();

// 3. instanciate the server
$server = new SoapServer(null, array("something"));

// 4. set the class to use
$server->setClass('UserService');

// 5. set persistance mode
$server->setPersistence(SOAP_PERSISTENCE_SESSION);

// 6. handle the request
$server->handle();
?>

down

boogiebug at gmail dot com ¶

16 years ago

setPersistence works only for a single instance of service class.

To use multiple instance of services objects, you need to instantiate the classes into objects and use an undocumented SoapServer's method - setObject() to add the service object into the SoapServer object, and handle the service object persistence with $_SESSION instead.

For example:

$ServiceObjects = array()
$ServiceObjects[0] = new ServiceClass1();
$ServiceObjects[1] = new ServiceClass2();
$ServiceObjects[2] = new ServiceClass3();

$_SESSION['ServiceClass1'] = $ServiceObjects[0];
$_SESSION['ServiceClass2'] = $ServiceObjects[1];
$_SESSION['ServiceClass3'] = $ServiceObjects[2];

...

$Servers = array()
for ( $i = 0; $i < count($ServiceObjects); i++)
{
  $s = new SoapServer($wsdl);
  $s->setObject($ServiceObject[$i]);
  $Servers[] = $s;
}

...

$Server[$i]->handle()

...

down

jan at pinna dot nl ¶

16 years ago

I found that using both modes (SOAP_PERSISTENCE_SESSION and SOAP_PERSISTENCE_REQUEST) cannot be used simultaniously. Because it didn't work at once, I started experimenting by using different settings and as stated below in the comments, "...also use SOAP_PERSISTENCE_REQUEST to save objects between requests" led me to think it was nessecary to use both modes. Well, it might for others, be but for me it turned out a day of freaking out ;) (trying all kinds of session stuff, etc etc).
Also, if persistence doesn't work, please check if session_start() is called somewhere in the script and try not to call it twice or whatsoever: it won't work...

down

jared at ws-db dot com ¶

19 years ago

I had some issues getting session persistence (SOAP_PERSISTENCE_SESSION) to work. I finally got it working after setting session.auto_start=0, and then only calling session_start() in the script containing the SoapServer. Maybe this is obvious, but took me a bit to figure it out.

I only tried it with session.use_cookies=1, so if the settings above don't work for you, make sure cookies are enabled, though it may work without the need for cookies.

down

cperez1000 at hotmail dot com ¶

19 years ago

Always remember to place the "setPersistence" method before the handle method, otherwise it won't work.  It sounds obvious, but it's still a very common mistake, since no errors are shown.

down

doug dot manley at gmail dot com ¶

16 years ago

When using "SoapServer::setPersistence( SOAP_PERSISTENCE_SESSION )", you apparently MUST include the class that was used in "SoapServer::setClass()" BEFORE any "session_*" commands.

I found this out using "__autoload()" and a whole lot of "syslog()"; it kept failing to include the class that I was using for my soap server, but that class is ONLY ever referenced by the page itself, and even then only for the purposes of setting the class for the soap server; none of my code would ever cause it to autoload.  The problem was that I was including my session-handling code first.

If the session gets started BEFORE the page defines the class definition, then persistence CANNOT happen.

The order should be:
1. Include the class for use with the soap server.
2. Start up your session.
3. Set up your soap server.
4. Handle your soap request.

＋add a note