ZF-7609: Zend_Queue should support serialization


Serialize a {{Zend_Queue_Adapter_Array}}-{{Zend_Queue}} should be possible.

{{Zend_Queue}} doesn't have a __sleep() function and {{Zend_Queue_Adapter_Array::__sleep()}} only specify {{_data}} variable.

If my {{Zend_Queue}} was to be stored in a {{Zend_Session_Namespace}}, with the following code:

$sessionNs = new Zend_Session_Namespace('ArrayQueue');
$sessionNs->queue = new Zend_Queue(
    array('name' => 'sessionQueue')

No problem is to be noticed with {{$sessionNs->queue}} until the next call to the page (for which unserialization runs). Then the following code:

$sessionNs = new Zend_Session_Namespace('ArrayQueue');

have not been correctly reset at unserialization.


Out of curiosity, why do you want to put an instance of Zend_Queue in a session?

A good reason for saving the Zend_Queue, particularly the array queue, is to debug a your application. Another good reason, is that your application has just received a term signal or you otherwise want to preserve state. Also unit testing... :)

There is code in Zend_Queue_Adapter_Array that will do this for you: getData(), setData().

$queue->getAdapter()->getData(); data can also be passed in the options when constructing the Array adapter.


I am a bit wary of adding __sleep() to Zend_Queue, because you are then saving connection information to "session", which would include the username, host, password. Also, none of the other adapters can be serialized like Zend_Queue_Adapter_Array.


Justin do you have any thoughts? I can see a good argument here for being able to Serialize an Array queue, however this functionality wouldn't carry over to any of the other adapters.


I agree. I think this would work for the Array adapter, but probably not any of the other ones because they deal with external resources. I think it's cleaner just to not include serialization support at all.

@Dolf Schimmel: I run into that "issue" when trying to implement some redirection queue for a administration backoffice module. The goal is to resolve the complexity of determine if client should be redirected to "/admin/add-user" after having completing "/admin/add-company" (for example) All "admin" actions may add an URL to the common queue and stop worrying about it, changing the "action-pipeline". Then a common (inherited) method (called by {{Zend_Controller_Action::postDispatch()}}) deals with the Queue: dequeueing, if possible, an URL and redirecting to it.

As that queue must be persistent between each query I've chosen session.

In the past I used a simple self-made Queue class (production server is not running PHP 5.3.0 which has {{" rel="nofollow">SplQueue}}) but as I was code-cleaning the application I wanted to give {{Zend_Queue}} a try (whose Adapter-based approach is quite attractive).

So my {{Zend_Queue}} is stored in the session but data don't persist.


@Daniel Lo: About {{Zend_Queue_Adapter_Db}}, we could always imagine not to store sensitive informations and add some "reconnect" feature (as in {{Zend_Db_Table_Row}}?) but I admit that the main goal of serialization is persistence, which is already offered by databases :)


@Justin Plock: I understand that, for now, most of {{Zend_Queue_Adapter}} would have few benefits of implementing serialization. But isn't what {{Zend_Queue_Adapter_AdapterInterface::isSupported()}} and {{Zend_Queue_Adapter_AdapterInterface::getCapabilities()}} are for? Dealing with "implementation" differences? I can't think of any other {{Zend_Queue_Adapter}} that would need serialization but I think building a frame is better than a plain solid wall (that allows extensibility).

@Claude Duvergier

I can see how your request would be an interesting change to the array adapter and I can see how it would be useful.

However, I still believe that making Zend_Queue serializ-able is a bad idea.

ActiveMQ, Memcacheq, Db, and any probably any other Zend_Queue's added on in the future won't support this feature, making this a kind of "one" of solution just for the Array adapter (Justin's argument).

In regards to your second comment in regards to building a frame, I agree. This issue came up in:, the email to Matthew wasn't included in the ticket (rather lengthy). The bulk of the issue was how to use the unique features from each adapter, but keep the code generic enough for common usage.

As a side note, you can also just create your own class an inherit from Zend_Queue class and overload __sleep() to make it serializable.

If more people comment on this and want this feature, I'll be happy to add it in, but unless there is more community support for a serialiable Zend_Queue, I won't consider this feature until Zend Frameworks 2.0.

I dropped this issue from Major & bug to minor priority and a new feature request.

@Daniel Lo: Thank you for these informations.

I'll stick with my {{Zend_Queue::__sleep()}} overloading for now and see how that new feature evolves.