Objetos persistentes y concurrencia en PHP
Raúl Jiménez Ortega
pero se me plantearon algunas dudas que nunca antes había tenido con
PHP, estas eran sobre la persistencia de objetos y el control de la
concurrencia ya que me iban a hacer falta para construir el sistema (y
los scripts escritos en PHP una vez ejecutados mueren, y por tanto
inicialmente no sabía cual iba a ser la solución).
Ahora me han venido de nuevo estas preguntas a la cabeza (por un
comentario que le hice el otro día a un profesor hablando sobre EyeOS,
un Web Desktop que a los que no lo conozcais os recomiendo probar) y
me he puesto a investigar, la cuestión es que acabo de conocer un
nuevo conjunto de funciones de PHP que no conocía y que parecen
resolver mis problemas:
- Seriación de objetos, objetos en sesiones
http://www.php.net/manual/es/language.oop.serialization.php
- Semaforos:
http://www.php.net/manual/es/ref.sem.php
Me había planteado hacerlo en PHP porque quería hacer un editor libre
y quería que funcionase en la mayoría de los servidores de hosting
(quería evitar lenguajes menos extendidos en el desarrollo web).
Así que a simple vista me parece cada vez más viable hacerlo así.
Antes me planteé si la mejor opción sería usar un objeto "centinela"
en Java que controlase estas cosas pero ya no lo veo tan necesario.
¿Qué pensáis al respecto?
Aún no me voy a poner con el tema, pero me gustaría hacerlo algún día
y creo que podría ser un tema interesante de discusión.
¡Un saludo!
![[PiNo]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVKe-VpbIvCD0LEJpJkdixLHsit3jTeRhcpBEmJoedis97D2ItwuQ=s40-c)
[PiNo]
Raúl Jiménez Ortega
La cosa es que como la idea era hacerlo en tiempo real y tal, pensaba que usar bases de datos (con tantas consultas), 1 consulta por segundo por cada usuario que esté editando documentos en el sistema iba a ser menos eficiente.
Otro problema que provisionalmente se puede solucionar con AJAX, sería que el servidor pudiese notificar al cliente cuándo se ha realizado un cambio ya que Apache aún no soporta COMET (aunque Apache Tomcat sí, supongo que será para JSP). Y no se me ocurre otra forma de hacerlo, xq los sockets no se pueden usar para conectar cliente-servidor que yo sepa.
Y una duda, si se lanza un script en PHP con un bucle a true hasta que alguien lo notifique lo contrario (y durmiendolo con sleep), si otro usuario llama al mismo script se sirve?(esto lo tengo que probar). Osea pueden haber dos instancias del mismo script php en memoría simultaneamente? (supongo que sí).
¡Un saludo!
[PiNo]
Yo lo había planteado hacer por ficheros (el bloqueo) y no por párrafos y por otra parte, tener un fichero para cada párrafo.... lo veo muy bestia.
No entiendo a qué te refieres con lo de los sockets.
Lo de que se puedan ejecutar varios scripts de PHP al mismo tiempo es seguro.
Raúl Jiménez Ortega
Google Docs y EtherPad ya ofrecen este servicio, pero no conozco herramientas libres que funcionen bien. SynchroEdit es una que usa un centinela en JSP (creo recordar) pero cuando lo intenté probar en el servidor (la demo) no me funcionaba.
Con lo del socket me refiero a usar una conexión cliente servidor usando los sockets de PHP, pero para eso tendría la máquina del cliente soportar estas conexiones por sockets y que la página del navegador fuese el encargada de recibir los mensajes (y creo que esto ya es demasiado pedir).
Gracias por la aclaración!!
Salu2!
--------------------------------------------------------------------
Raúl Jiménez Ortega
Tlf: 652 38 43 50
CV: https://www.xing.com/profile/Raul_JimenezOrtega
Blog: nefertec.wordpress.com
Twitter: www.twitter.com/hhkaos
Asociación de webmasters: www.webmastergranada.es
Iniciador: www.iniciador.com
Linkedin: /www.linkedin.com/pub/dir/raul/jimenez%20ortega
Xing: www.xing.com/profile/Raul_JimenezOrtega
[PiNo]
Raúl Jiménez Ortega
"La cosa es que como la idea era hacerlo en tiempo real y tal, pensaba que usar bases de datos (con tantas consultas), 1 consulta por segundo por cada usuario que esté editando documentos en el sistema iba a ser menos eficiente."
:(, a ver si los de Apache se ponen las pilas y sacan una nueva versión con COMET!jeje
Salu2
P.D: entonces hemos dicho que en ese caso sería mejor un GBD o el sistema de ficheros?, yo pensaba en cargar el fichero en un objeto mientras se esté editando y serializarlo hasta que se termine, luego (al terminar la edición) pasarlo a la BD.
[PiNo]
Yo el almacenamiento lo haría en una base de datos, pero lo de los ficheros no me parece mal si es algo temporal y hay en esta lista gente con mucha más idea que yo.
Raúl Jiménez Ortega
Si queréis ver como está implementado este sistema aquí hay un gráfico bastante clarificador:
http://synchroedit.com/index-images/SynchroEdit%20Diagram.png
Supongo que lo de la sincronización visto lo visto será tb con AJAX cada X segundos (xq aunque use Java creo que no usa Tomcat).
Me he descargado el código (por si peta antes de que pueda meterle mano). De todas formas la demo se me sigue quedando en "Connected to server; loading document...". De todos modos seguro qe será útil mirar el código antes de plantearse que enfoque darle.
En cuanto a lo de los ficheros me parece que será más fácil de gestionar así, xq así puedes cargar objetos automáticamente (dsd hace unas versiones tb se guardan las funciones), sin tener que crear una función a medida que almacene y recupere los datos de la BD. Lo único que habrá que hacer es evitar que dos scripts recuperen al mismo tiempo el objeto y así terminen machacando las modificaciones de otro. (por eso lo de la consistencia).
Osea habría que usar como sección crítica la lectura y escritura del objeto que controlase la concurrencia de las ediciones para cada documento. ¿no?
Luego supongo que si pasado X tiempo no se reciben peticiones de los clientes (de actualización) se tendría que programar un script (con Cron por ejemplo) que periódicamente fuera recogiendo objetos que no hayan sido cerrados por los clientes.
Salu2!
F. Martín Umpiérrez
Si se intenta algo similar en php, supongo que por eso dices lo de serializar, habrian X scripts en PHP que estaría serializando y deserializando un mismo objeto, ¿no?, entonces podria suceder que hubieran varias instancias del mismo objeto que hubieran sido deserializadas en el mismo lapso de tiempo.
Hace tiempo tuve un problema similar que queria resolver con php, lo que llegué a pensar fue usar funciones de php para solicitar un area de memoria pero que yo recuerde (hace casi 4 años de esto) no eran portables, estaban bastante ligadas al SO sudyacente. La idea seria solicitar un area de memoria que todos los scripts php que interactuen sobre un mismo documento compartan, y mediante esa memoria, sincronizarse de alguna manera
Raul Jimenez Ortega
Jeje, la cosa sería que los scripts usasen semáforos para evitar el
problema que dices de serializar el mismo objeto en diferentes scripts,
supongo que el procesamiento será rápido y así soportaría varios
usuarios interactuando rápidamente.
La idea inicial que tenía sería usar un objeto de la clase "X" que
mantuviese en todo momento el estado del documento, de las personas que
lo están editando y del párrafo en el que se encuentra cada una. Así se
podría evitar que varias personas editasen simultaneamente el mismo
párrafo y se podrían informar al resto de usuarios quienes están
viendo/editando el archivo.
No se si lo de la memoria será más eficiente, por lo que he visto el
tema de la serialización se mejoró en la versión 4 y pico y en cuanto a
semáforos no sabía ni que existían xD.
Salu2
F. Martín Umpiérrez escribió:
> el problema es que php no es un sevidor de aplicaciones y por eso
> supongo que recurren a java, de esa manera se puede mantener un objeto
> permamente que se encargue de la concurrencia.
>
> Si se intenta algo similar en php, supongo que por eso dices lo de
> serializar, habrian X scripts en PHP que estaría serializando y
> deserializando un mismo objeto, ¿no?, entonces podria suceder que
> hubieran varias instancias del mismo objeto que hubieran sido
> deserializadas en el mismo lapso de tiempo.
>
> Hace tiempo tuve un problema similar que queria resolver con php, lo
> que llegué a pensar fue usar funciones de php para solicitar un area
> de memoria pero que yo recuerde (hace casi 4 años de esto) no eran
> portables, estaban bastante ligadas al SO sudyacente. La idea seria
> solicitar un area de memoria que todos los scripts php que interactuen
> sobre un mismo documento compartan, y mediante esa memoria,
> sincronizarse de alguna manera
>
> 2009/5/31 Raúl Jiménez Ortega <hhk...@gmail.com <mailto:hhk...@gmail.com>>
> <mailto:jllop...@gmail.com>>
>
> No sé cómo funcionarán los centinelas de JSP, pero supongo que
> de una forma muy similar, el cliente tendrá que estar haciendo
> peticiones.
>
> Yo el almacenamiento lo haría en una base de datos, pero lo de
> los ficheros no me parece mal si es algo temporal y hay en
> esta lista gente con mucha más idea que yo.
>
> El 31 de mayo de 2009 11:57, Raúl Jiménez Ortega
> <hhk...@gmail.com <mailto:hhk...@gmail.com>> escribió:
>
> Ahá, como sospechaba cuando comente esto:
>
>
> "La cosa es que como la idea era hacerlo en tiempo real y
> tal, pensaba que usar bases de datos (con tantas
> consultas), 1 consulta por segundo por cada usuario que
> esté editando documentos en el sistema iba a ser menos
> eficiente."
>
> Lo malo entonces es que sobrecarga el servidor con
> peticiones innecesarias, lo cual puede ser válido en un
> sistema con pocos usuarios. Entonces de momento solo
> quedaría la alternativa de usar un centinela en JSP
> (Apache Tomcat) que soporte COMET si se quiere evitar eso.
>
> :(, a ver si los de Apache se ponen las pilas y sacan una
> nueva versión con COMET!jeje
>
> Salu2
>
> P.D: entonces hemos dicho que en ese caso sería mejor un
> GBD o el sistema de ficheros?, yo pensaba en cargar el
> fichero en un objeto mientras se esté editando y
> serializarlo hasta que se termine, luego (al terminar la
> edición) pasarlo a la BD.
>
>
> 2009/5/31 [PiNo] <jllop...@gmail.com
> <mailto:jllop...@gmail.com>>
>
> Sí, el servidor no puede enviar información al cliente
> de forma asíncrona, puedes hacer que el cliente haga
> una petición cada X segundos.
>
> El 31 de mayo de 2009 11:51, Raúl Jiménez Ortega
> <hhk...@gmail.com <mailto:hhk...@gmail.com>> escribió:
> <http://nefertec.wordpress.com>
> Twitter: www.twitter.com/hhkaos
> <http://www.twitter.com/hhkaos>
> Asociación de webmasters: www.webmastergranada.es
> <http://www.webmastergranada.es>
> Iniciador: www.iniciador.com
> <http://www.iniciador.com>
> Linkedin:
> /www.linkedin.com/pub/dir/raul/jimenez%20ortega
> <http://www.linkedin.com/pub/dir/raul/jimenez%20ortega>
> Xing: www.xing.com/profile/Raul_JimenezOrtega
> <http://www.xing.com/profile/Raul_JimenezOrtega>
>
>
>
> 2009/5/31 [PiNo] <jllop...@gmail.com
> <mailto:jllop...@gmail.com>>
>
> Creo que los requisitos que estás planteando
> son un poco exigentes. No sé si has visto cómo
> funcionan las páginas de Google Groups, se
> limitan simplemente a mostrar un aviso si hay
> una persona que ya está editando el mismo
> fichero y los cambios no se guardan hasta que
> l usuario no lo indica. Yo creo que son eso ya
> sería suficiente.
> Yo lo había planteado hacer por ficheros (el
> bloqueo) y no por párrafos y por otra parte,
> tener un fichero para cada párrafo.... lo veo
> muy bestia.
>
> No entiendo a qué te refieres con lo de los
> sockets.
>
> Lo de que se puedan ejecutar varios scripts de
> PHP al mismo tiempo es seguro.
>
>
> El 31 de mayo de 2009 11:24, Raúl Jiménez
> Ortega <hhk...@gmail.com
> <mailto:hhk...@gmail.com>> escribió:
> <mailto:jllop...@gmail.com>>
>
> Yo conocía que existía la
> serialización en PHP (por un trabajo
> que hice para PDO), pero no la he
> utilizado nunca. La cuestión es ¿para
> qué la necesitas? ¿Qué información
> quieres almacenar que no puedas tener
> en una base de datos (que te permitirá
> acceder a esos datos de una manera
> mucho más eficiente)? Si es porque no
> quieres que varias personas accedan a
> un recurso puedes bloquear filas al
> menos con una de las dos tecnologías
> de almacenamiento de MySQL (ahora no
> reduerdo si con MyISAM o InnoDB).
>
> El 31 de mayo de 2009 3:27, Raúl
> Jiménez Ortega <hhk...@gmail.com
> <mailto:hhk...@gmail.com>> escribió:
> --~--~---------~--~----~------------~-------~--~----~
> Has recibido este mensaje porque estás suscrito a Grupo "UGR
> Webmasters" de Grupos de Google.
> Si quieres publicar en este grupo, envía un mensaje de correo
> electrónico a ugr-web...@googlegroups.com
> Para anular la suscripción a este grupo, envía un mensaje a
> ugr-webmaster...@googlegroups.com
> Para obtener más opciones, visita este grupo en
> http://groups.google.com/group/ugr-webmasters?hl=es.
>
> -~----------~----~----~----~------~----~------~--~---
>
--
Raúl Jiménez Ortega
Tlf: 652 38 43 50
CV: http://nefertec.wordpress.com/about/
Raúl Jiménez Ortega
sentido entonces meterle mano a este proyecto de edición colaborativa?
XD
http://www.youtube.com/watch?v=v_UyVmITiYQ&feature=related#t=35m35s
Expongan sus respuestas aquí xD.
The future is comming quite fast! xD
> > <mailto:jllopezp...@gmail.com>>
> > <mailto:jllopezp...@gmail.com>>
> > <mailto:jllopezp...@gmail.com>>
> > Creo que los requisitos que estás planteando
> > son un poco exigentes. No sé si has visto cómo
> > funcionan las páginas de Google Groups, se
> > limitan simplemente a mostrar un aviso si hay
> > una persona que ya está editando el mismo
> > fichero y los cambios no se guardan hasta que
> > l usuario no lo indica. Yo creo que son eso ya
> > sería suficiente.
> > Yo lo había planteado hacer por ficheros (el
> > bloqueo) y no por párrafos y por otra parte,
> > tener un fichero para cada párrafo.... lo veo
> > muy bestia.
>
> > No entiendo a qué te refieres con lo de los
> > sockets.
>
> > Lo de que se puedan ejecutar varios scripts de
> > PHP al mismo tiempo es seguro.
>
> > El 31 de mayo de 2009 11:24, Raúl Jiménez
> > Ortega <hhk...@gmail.com
> > <mailto:hhk...@gmail.com>> escribió:
>
> > Pues para que cuando dos personas estén
> > editando un fichero simultaneamente no
> > puedan editar el mismo
>
>
> leer más »
>
> hhkaos.vcf
> < 1 KBVerDescargar
>
> smime.p7s
> 4 KVerDescargar