SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 64

Hybrid View

  1. #1
    SitePoint Addict
    Join Date
    Oct 2003
    Location
    Malaysia
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Object Persistence in PHP?

    Just wondering about this (there is probably a not too difficult answer to this, but I can't seem to find the answer online )

    How do you keep an object across multiple pages? Say you have a class called Users that pretty much models everything about a user (user name, user id, age, location, user type etc etc.) and you query the database based on the user's login to form the object then store the user_id as a session information. The user clicks on the send a message link, and you'll have to read the user_id for the session and query the database again.

    Is there a better way of doing this, or is my concept totally wrong to begin with?

    Thanks

  2. #2
    SitePoint Member
    Join Date
    Jul 2005
    Location
    Montreal
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    hey,

    Due to the transaction-less nature of the web, you require these sessions along with session keys to keep track of your users. If you were to keep an object persistent, it would be no different than storing the information in the session (although be weary of security) or simply query the db at each request.

    Since most pages require some db transaction, you won't suffer a serious hit to your server(s) and by abstracting the code into an include, you can avoid repetition.

    e.g. header.inc.php

    if (isset($_SESSION['uid']))
    {
    $GLOBALS['user'] = db_find_user_by_id($_SESSION['uid']);
    }

    hope this helps.

  3. #3
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually the best is to keep the users ID in the session and retrieve the information from the database each time you need it.
    Basicly, if you take the info and put it all in a session you risk to have different data between the "session user" and the "database user".
    In his session time the user may have got a higher ranking, or more forum posts, than depicted in the session.


  4. #4
    SitePoint Enthusiast
    Join Date
    Jan 2006
    Location
    Amsterdam
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by REMIYA View Post
    Actually the best is to keep the users ID in the session and retrieve the information from the database each time you need it.
    Basicly, if you take the info and put it all in a session you risk to have different data between the "session user" and the "database user".
    Haven't though of this before, good point. Session should save as few data as possible since its not lazy and everything is available anytime..
    thanks for the hint!!

  5. #5
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As everyone else here has stated it's very well possible to create some type of "object persistance" in php, however I'd say that it's both uneccessary and very counter intuative to php's way to do things(build up, tear down).

    Also, for example in Java it's very common with object persistance - but my whole stance on this it's very counter intuative to go against the statelessness of the http protocoll.

    Just my 0.02$

  6. #6
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    but my whole stance on this it's very counter intuative to go against the statelessness of the http protocoll.
    You go against this all the time in PHP, you are just using the database and the file system instead of memory. In Java its rather nice that you can store local caches, configuration details and sessions in memory, whereas with PHP you can used memcached but it is running in a seperate prcoess and is less efficient.

    For some applications having the ability to persistent objects can make the application much faster than anything you could do with PHP. This gives the user a better experience. On the other hand its less useful for applications that are dealing with large amounts of data that can't easily be cached (most successful large php applications seem to be of this type).

  7. #7
    SitePoint Addict rvdavid's Avatar
    Join Date
    Nov 2006
    Location
    Australia
    Posts
    233
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Object persistence is possible. You can serialise an object for storage (either to a file or in the session super global) and unserialise when you need it.

    HTH

    Regards,

  8. #8
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by freak View Post
    The user clicks on the send a message link, and you'll have to read the user_id for the session and query the database again.

    Is there a better way of doing this, or is my concept totally wrong to begin with?
    You shouldn't be afraid of querying the database again on each request. That's the nature of PHP-applications, and any loss of efficiency is made up for by other means. Sessions are not meant to be used for caching persistent data. Most likely, it's going to be slower than querying the database anyway, since sessions are file-based. Databases on the other hand, are intelligent enough to cache recent results in memory.

  9. #9
    SitePoint Addict rvdavid's Avatar
    Join Date
    Nov 2006
    Location
    Australia
    Posts
    233
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Sessions are not meant to be used for caching persistent data. Most likely, it's going to be slower than querying the database anyway, since sessions are file-based. Databases on the other hand, are intelligent enough to cache recent results in memory.
    Gah!! guess who's refactoring a year old module then :P (yes, me ).

    It was something I picked out from php.net and was actually a proof of concept that had made its way into actual production code.

    I was totally unaware that this is the wrong way of doing things. I use it for an insignificant part of an old application I've made (a shopping cart-like object), I never really revisited or even had to touch it since it worked the whole time.

    In light of kyber's correction, while it IS possible to persist objects in sessions or files, it's discouraged that you do so.


    Regards,

  10. #10
    SitePoint Addict
    Join Date
    Oct 2003
    Location
    Malaysia
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmmm, then wouldn't it be easier if you just used cookies to store a person's user id instead of using PHP's session handling?

    And if PHP's session management is ran off a file (I remember reading that somewhere), wouldn't it be grossly inefficient to run a site like say, wikipedia?

  11. #11
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by freak View Post
    Hmmm, then wouldn't it be easier if you just used cookies to store a person's user id instead of using PHP's session handling?
    The difference between using a cookie and PHP-sessions, is that data stored in the session are only accessible from the server side script. So you can put trusted information in there.

    Quote Originally Posted by freak View Post
    And if PHP's session management is ran off a file (I remember reading that somewhere), wouldn't it be grossly inefficient to run a site like say, wikipedia?
    For very large scale systems, you can set up sessions to be stored in a database instead, which makes it possible to distribute the load across multiple servers. But it's still set up and torn down on a per request basis.

    The performance issue isn't the biggest problem with the use of sessions though. If you pull data out of the database and put it in session, you have two copies of the data. This is something that you generally want to avoid in software, since it leads to concurrency issues. With web applications, the problem is even greater. The nature of the web is stateless, but if you store application state in sessions, you break this feature. This means that your users can't bookmark pages, or use the back-button of the browser. You may also get unexpected behaviour if the user has multiple windows open to the same application. As a general rule of thumb, try to minimize use of sessions, and try to use query-parameters to maintain application state.

    On the flipside - If your application is completely stateless, it's very easy to appply caching techniques on top of it.

  12. #12
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    Melbourne
    Posts
    362
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    For very large scale systems, you can set up sessions to be stored in a database instead, which makes it possible to distribute the load across multiple servers. But it's still set up and torn down on a per request basis.
    Or you can use memcache servers or something similar like shmop to manage often accessed data, which will generally be a lot faster than either db or file access... if your site does in fact need that level of performance. You'll probably hit on other bottlenecks before needing shared mem access, however if you get to the level of millions of daily hits, there's a pointer

  13. #13
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Umm...

    > ..., however if you get to the level of millions of daily hits, there's a pointer

    I doubt that if you have millions of visitors, shared memory would have any real benifit to you, in regards to tackling any performance issues you would be facing. I'm not saying that there isn't a benifit, not at all; But with the shear amount of resources required to satisfy that amount of users, shared memory alone wouldn't be enough.

    If you have millions of requests then you are looking at scaling with hardware for the most part. If you scale horizontally, then you'd be looking to scale your application at the same time. With an LAMP architecture that is what you'd be working towards anyways...

  14. #14
    SitePoint Addict
    Join Date
    Apr 2004
    Location
    Melbourne
    Posts
    362
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston View Post
    Umm...

    > ..., however if you get to the level of millions of daily hits, there's a pointer

    I doubt that if you have millions of visitors, shared memory would have any real benifit to you, in regards to tackling any performance issues you would be facing. I'm not saying that there isn't a benifit, not at all; But with the shear amount of resources required to satisfy that amount of users, shared memory alone wouldn't be enough.
    You'd be surprised at just how much something like memcache can boost performance, especially when dealing with a DB and session hungry application. Obviously you're probably going to need to scale out horizontally if you're coping with that much traffic, but in past experience it has definitely helped to remove bottlenecks caused by calls to session_start.

  15. #15
    SitePoint Zealot the DtTvB's Avatar
    Join Date
    Jul 2006
    Location
    Thailand
    Posts
    162
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You can serialize an object to make it a string, and you can unserialize when you need to restore.

  16. #16
    SitePoint Wizard REMIYA's Avatar
    Join Date
    May 2005
    Posts
    1,351
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by the DtTvB View Post
    You can serialize an object to make it a string, and you can unserialize when you need to restore.
    Lately I found out that the functions serialize and unserialize take very much time . After some tests I found that the old var_dump takes much less time, and since it is pure PHP later is faster to retrieve

  17. #17
    SitePoint Addict
    Join Date
    Oct 2003
    Location
    Malaysia
    Posts
    231
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks people for explaining

    We'll never ever reach more than a million hits a day, so no worries about that But I suppose those slightly more pedantic can have their fun

  18. #18
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    persisting data to a filesystem and/or database is not the same thing
    I really don't see the difference. In one case you can store your object (or the data from the object) in a file or you can store the exact same data in memory. I don't see how storing data in a different medium makes what you are doing conceptually different. Also, a PHP applicatoin that uses file-based Sessions is just as stateful as an app that uses memory based sessions. Both have the same issues when you scale.
    What PHP looses in terms of speed when it comes to object persistance it often makes up in other areas. Also, as soon as an application grows a bit the amount of data handled escalades quickly and caching becomes harder and harder.
    What other areas? I can only think of one advantage this gives PHP - that it makes it suitable for shared hosting environments. Also, I don't think data size has much to do with how well caching works. Rather its how the data is being accessed, if on a given day 90% of the queries are for 5% of the data then its very easy to cache. There is also a lot of data that is essentially configuration info that is stored in the database when using PHP, this info is often accessed on every request yet could be easily cached if such a feature was available.

    Anyhow, I find justifying these limitations has good for scalability rather funny.
    They don't make your application stateless, any interesting application on the web is stateful. They don't make your application more scalable, in Java you can just as easily make your application distributable if desired (and likewise for .NET). These "features" are part of PHP because its primarily used to run small web apps using shared hosting (and PHP is great for this context), they make little sense outside of that context.

  19. #19
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > Couldn't have put it better myself.



    The fact that everything dies at the end justifies the huge benifit that PHP has over a multitude of other languages; It's not my problem if someone cannot understand the purities of PHPs architecture that, that brings to web development.

    Don't look at it from the script point of view, but look at it from the hardware point of view instead if you want to understand more...

    > Used wisely such feature could be a tremendous boost on performance of our
    > applications.

    I shouldn't think so; Not at all in fact. Take a look at the resource hog that Java has become in recent years? Java as a language is well smart, but as a technology it's horse manure, technically speaking of course

    This what you are asking of PHP is not what you want, and in fact it proberly would kill PHP right there and then. You, yourself will not see the benifits of PHPs architecture, if you've never moved an application with a given user base, from one server to another server...

    I'm not talking about shared hosting either PHP as it stands is perfect, even more perfect once PHP6 arrives, and honestly people, other technologies today are jealous of what PHP is, and what it has become, and what it will become in the future.

  20. #20
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    > other developers mainly just crack jokes about PHP.

    They are cracking the jokes because they are envious of the success of PHP; It's a basic human need to make fun of something or someone they don't understand, nor have the interest to understand.

    At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?

    > I have no trouble running Java apps on old P3 servers.

    What sort of applications were you running, and could you run one of todays enterprise level applications on one of your Pentium 3s? I sort of know your answer already...

    > PHP's platform only uses less resources for small apps, hence why its so great for
    > shared hosting.

    Shared hosting has got nothing to do with it; In fact, if anything it just goes to show you just how performance oriented PHP is in regards to the limited resources that shared hosting are, by their nature, in relation to the amount of load on that given server.

    PHP from what I can remember on reading something on Zend uses about 40% less memory than typically what is required by the likes of Java; Unfortunately you'll just have to take my word on that as I don't recall the URL... But the differences were far from marginal to say the least, between Java and PHP; Again, that of course is dependent on a lot of other variables, etc.

    Maybe the results were shewed a bit, I don't know - I didn't perform the benchmark, but the feeling I have is that PHP performs better than what Java would perform on reduced technology, hardware wise that is.

    > And these benefits are?

    Have you not heard of the share nothing phrase?

    > This overhead is even greater if the app and the database aren't on the server.

    That isn't an issue as such to do with PHP though... It's a problem that is commonly shared with all technology using the Internet. Latency it's called I think?

  21. #21
    SitePoint Enthusiast
    Join Date
    Oct 2005
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Talking

    Quote Originally Posted by Dr Livingston View Post
    At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?
    Can you name just one PHP e-commerce that has been as much a success as OSCommerce ?

    Stefano

  22. #22
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    At the end of the day though, can you name just one technology that has been as much a success as PHP? Honestly I mean?
    Lets get real here. Nobody denies that PHP has been sucessful in some sense, but PHP success is primarily with small web apps. Also I have no idea what metric you are using for "success". Sure if we are talking about small web apps PHP has been largely successful, but Perl + cgi was also very sucessful in this same domain. But if you are talking about backends then PHP is rarely used, PHPs "share nothing" architecture makes no sense in these contents.
    Have you not heard of the share nothing phrase?
    Ugh, sure I've heard that marketing buzz word. Now, what are the real advantages of PHP for large applications? How does not sharing data between requests benefit a large application? It doesn't benefit scabability, the application will be scalable if its distributable (which can easily be done with Java or .NET). On the other hand the advantages for small apps are clear.
    That isn't an issue as such to do with PHP though... It's a problem that is commonly shared with all technology using the Internet.
    Sure, but if you could persistent objects than you can boost performance by caching. And its not just a small boost, accessing a local in-process cache is dramatically faster than accessing a cached query from a database running on a remote server. Almost every language has a way of doing this (Perl with mod_perl, Python with mod_python, java out of the box etc), but not PHP.

  23. #23
    SitePoint Guru
    Join Date
    Feb 2006
    Location
    Pittsburgh, Los Angeles
    Posts
    706
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You don't. Session is a method for storing state at the server.
    You said "but the state must be transferred to the client", are you suggesting that one shouldn't use sessions? Maybe, I misread your initial comment.
    But that argument assumes that you can get away with not connecting at all.
    Right in PHP that doesn't happen much because you store so much junk in the DB, but that isn't necessary with other platforms. So in many cases you can get away with no database calls on cached data.
    Oh, and I believe that you can use connection pooling if the db is non-local.
    PHP doesn't allow connection pooling, rather you can only have persistent connections in PHP. This differs in fundamental ways from connection pools, it would work ok in apache 2 with threads....but PHP isn't thread friendly (or I should say many of the extensions commonly used aren't)

    Anyhow, its not just the issue of creating a connection. Its also the cost to grab the data, grabbing cached data (usually stored in a hash) from local memory is extremely fast where as even if the DB is intelligently caching your data you still have to grab the data over a socket, which in the case of a remote database can be fairly expensive. I'm not suggesting that having the ability to persist objects is always useful, but in many cases it can boost performance significantly. Additionally, having the ability to persist objects does not effect the platforms ability to scale. Personally I find the "in PHP you can scale your app by just adding hardware" view rather naive, most of the PHP apps I have seen would not scale out of a single server as they are currently implemented.

  24. #24
    SitePoint Enthusiast
    Join Date
    Feb 2006
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Even though PHP has a stateless architecture, you can cache things in memory, just take a look at Memcached.

  25. #25
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't believe though that you can cache a resource, and that is what the discussion is about in part at least? Which... Has lead to this arguement between the architecture of PHP and other technology.

    I can't really express myself in a way that fits words on how PHPs architecture, being stateless so to speak (nothing lives once script execution ends) is better than other technology that retains state, nor can I find facts at the moment either.

    But there are blogs out there that describe better than what I could, as to why PHP is scales better in a lot of regards.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •