[RESOLVED] general php question: persistant objects

kakki

hello @ all,

i'm having this discussion with my java-collegues. they keep telling me that java is
better, more advanced .... ( blahblah ... i guess everybody has heard that kind of arguments )

they keep telling me about the advantages of a full application server.
i wanna end these rants and need answers from professional php-developers:

is there a way to keep objects after the page is rendered ?
what about connection pooling, is there something for that ?
now what about 2 threads running simultanously, are there means for that ???

thanks in advance,
kakki

Shrike

Firstly, PHP is not a multithreaded process. PHP is designed around an idea of 'shared-nothing', meaning each PHP process knows nothing about any other process which may be running.

This sort of follows on to the second point about connection pooling. Since there are no threads theres no point in having a connection pool.

There are several ORM products for PHP. Notable ones are Propel and Doctrine. In PHP object persistence typically means abstracting the database layer behind objects. These products have something in common with Hibernate for Java.

Java can also maintain objects in memory between requests, as a sort of global container. PHP has no equivalent to this.

I'm not even going to try to say whether one is better than the other. There is no right or wrong answer.

NogDog

Note that persisting objects within a given PHP session can be fairly simple by using [man]serialize/man and [man]unserialize/man. See "Serializing objects - objects in sessions" for more info.

kakki

@: thnx for the answer ... i was just hoping, that the php-guys have invented something like
it.( they added a gui-lib, so i thought that they maybe did sth more... )

maybe you are right and this whole php vs java/perl/python ... is sort of a religious question ....

@: i had the same idea, is there a framework, which provides persistant objects or do i have
to do it on my own ?

btw, i think i read about an application server from zend, is it worth it ???

piersk

TBH, I'm not sure if PHP vs Java is a very good comparison. I would have thought a better comparison would be PHP vs JSP (not JavaBeans tho).

@: Can JSP support threading and all the other things above?

NogDog

kakki wrote:
...
@: i had the same idea, is there a framework, which provides persistant objects or do i have
to do it on my own ?
...

I don't know, but it would seem a bit of overkill, since all you need to do is:

script_1.php:

<?php
// start of script:
require_once "myClass.php";  // load class definition
session_start();
$myObj = new myClass(); // instantiate object
// ...other processing, then...
// save object in session data:
$_SESSION['myObj'] = serialize($myObj);
?>

script_2.php:

<?php
// load class definition before unserializing object:
require_once "myClass.php";  // load class definition
session_start();
// retrieve object from session data:
$myObj = unserialize($_SESSION['myObj']);
// ...rest of script...
?>

Shrike

Nogdog - you don't need to serialize things being put into $_SESSION as the session handler does this for you. I'm not sure if the same holds true if you use [MAN]session_set_save_handler[/MAN] though.

NogDog

Shrike wrote:
Nogdog - you don't need to serialize things being put into $_SESSION as the session handler does this for you. I'm not sure if the same holds true if you use [MAN]session_set_save_handler[/MAN] though.

Good! Then it's even simpler than I thought and there's less reason for a "framework". 🙂

Shrike

Well it depends on your needs. Putting objects in a session is fine for simple or short term tasks. ORM frameworks like Propel assume that an application uses objects for data manipulation and a database for storage. They automate the repetitive tasks involved such as writing SQL queries.

Perhaps I am confused with the OP's use of the term object persistence 🙂

Sxooter

Also, the use of persistant objects often causes as many problems as it solves.

For instance, what about in a farm of x jboss machines? How are they supposed to maintain all that data and have it follow from one app server to another if your load balancer moves your session? There are several methods for doing this, jgroups, jms, etc... but they all have issues with scalability and reliability.

I'm reminded of Scotty from Star Trek. The fancier the plumbing, the easier it is to muck it up. Or something like that.

The reason I like php sessions so much is that you can implement sharing them in a farm with nothing more than an nfs or samba mount.

MarkR

kakki wrote:
- is there a way to keep objects after the page is rendered ?

No, there is not. PHP uses a shared-nothing model which does not allow any persistent data to be held in memory or shared memory.

You can of course persist objects into a file or database (or indeed, session which is just a special case of one of these), in which case they would have to be disassembled (e.g. by an ORM) or serialised.

- what about connection pooling, is there something for that ?

Connection pooling is a form of shared object. You should not need it. Just create a new connection on each page and let it be destroyed at the end. This does not normally create a major performance problem, but if your profiling data tells you that it is doing so, consider (carefully) using persistent connections once you understand all the issues and have load-tested your system.

- now what about 2 threads running simultanously, are there means for that ???

Two PHP requests can run at once. Depending on the web server, they may run in separate threads or separate processes. It really is up to the implementation what actually happens.

There is no native way of creating threads in PHP, but in some cases your code will run in a threaded environment.

If you need to do background tasks, I recommend creating daemon process(es) as necessary and having them communicate somehow.

Using threads explicitly requires care as it can be error-prone. PHP generally shields you from this kind of stuff.

In any case, developing on the assumption that there are shared objects between web server threads is naive, because your solution WILL NOT SCALE.

Even in Java, the shared objects will only be shared with other threads in the same process, not other processes, let alone other machines. A scalable web application will run on multiple machines out of NECESSITY.

Therefore, you can't really use them for anything important.

Of course some Java app servers support horrible protocols for trying to sychronise (serialisable) shared objects between servers in a pool - this is a bit icky. Try to avoid it. I can't imagine the performance of such a system being desirable.

Likewise, if you can avoid using sessions, that's even better as it reduces the coupling of your servers (a session must be locked so that other threads don't use it at the same time; this locking obviously creates contention) and therefore increases scalability.

Mark

Bunkermaster

MarkR wrote:
Connection pooling is a form of shared object. You should not need it. Just create a new connection on each page and let it be destroyed at the end. This does not normally create a major performance problem, but if your profiling data tells you that it is doing so, consider (carefully) using persistent connections once you understand all the issues and have load-tested your system.

there are times when the connection is not automatically cut. For example if you open 2 database connections without explicitly closing the first link you will have a huge sleeping connection count on your DB. I had the problem, now it's all managed by my db connection/debugging/whatnot classes but my previous record (on a quick and dirty job) was around 500 db connections stuck. Not too proud of it either :glare:

MarkR

Persistent connections should not be used without extreme care. Your database should be able to handle the maximum number of web server threads * number of database connections used per page.

The number of connections used per page should be kept to a minimum (ideally 1).

Any solution should be load-tested.

All non persistent connections are always closed by PHP at the end of the page. However, in principle each thread can be running a page, all at once.

Mark

kakki

thank you all for your enlightening answers,
now i have some arguments for these java-coders