Longhorn PHP 2023 - Call for Papers


(PHP 5, PHP 7, PHP 8)

SoapServer::setPersistenceActive le mode persistant de SoapServer


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

Cette fonction permet de changer la persistance d'un objet SoapServer entre les requêtes. Elle permet de sauvegarder les données entre les requêtes, au moyen des sessions PHP. Cette fonction n'a d'effet qu'après avoir exporté la liste des fonctions au moyen de SoapServer::setClass().


La constante de persistence SOAP_PERSISTENCE_SESSION rend uniquement les objets de la classe donnée persistants, mais non pas les données statiques. Dans ce cas, $this->bar au lieu de self::$bar.


SOAP_PERSISTENCE_SESSION serialise les données de l'objet entre les requêtes. Dans le cas des ressources, (par exemple PDO), __wakeup() et __sleep() devraient être utilisées.

Liste de paramètres


Une des constantes suivantes :

SOAP_PERSISTENCE_REQUEST - Les données de SoapServer ne sont pas persistantes entre les requêtes. C'est le comportement par défaut de tout objet SoapServer après appel à setClass().

SOAP_PERSISTENCE_SESSION - Les données de SoapServer persistent entre les requêtes. Ceci est réalisé en linéarisant les données de la classe SoapServer dans $_SESSION['_bogus_session_name'], et ainsi session_start() doit être appelée avant de passer sous ce mode de persistance.

Valeurs de retour

Aucune valeur n'est retournée.


Exemple #1 Exemple SoapServer::setPersistence()

class MyFirstPersistentSoapServer {
$resource; // (Par exemple PDO, mysqli, etc..)
public $myvar1;

public function
__construct() {
$this->__wakeup(); // On appelle notre wakeup pour relancer notre ressource

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

public function
__sleep() {
// On s'assure d'enlever $resource ici, ainsi nos données peuvent persister en session
// Si on oublie, la désérialisation lors de la prochaine requête échouera et notre objet
// SoapObject ne sera donc pas persistant entre les requêtes.
return array('myvar1','myvar2');

try {
$server = new SoapServer(null, array('uri' => $_SERVER['REQUEST_URI']));
// setPersistence() DOIT être appelée après setClass(), car le comportement de setClass()
} catch(
SoapFault $e) {
error_log("SOAP ERROR: ". $e->getMessage());

Voir aussi

add a note

User Contributed Notes 6 notes

csnaitsirch at web dot de
13 years ago
I want to give one example for the order of commands if you want to use a class in persistence mode.

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

// 2. start the session after defining or including the class!!

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

// 4. set the class to use

// 5. set persistance mode

// 6. handle the request
boogiebug at gmail dot com
15 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);
  $Servers[] = $s;



jan at pinna dot nl
15 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...
jared at ws-db dot com
17 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.
cperez1000 at hotmail dot com
18 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.
doug dot manley at gmail dot com
15 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.
To Top