How best to use php5 objects between pages?

A project I did awhile back stored php5 objects in elements of the
$_SESSION array between pages that were navigated on the site. There
were object classes representing teachers, and object classes
representing students that referenced teacher objects.

Then I happened to look at the temporary files created by sessions and
found much redundant data was stored in each file about the teachers
since they were referenced by every student in the same classroom.

I realize that I could have stored some persistent object data in a
database rather than in the objects. But there would be overhead either
way -- reading large session files each time the user navigates to a
new page, or querying the database each time the user navigates to a
new page.

So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be
useful between multiple pages on a site? When are objects stored in
sessions recommended over using database queries?

So my question is: Are php5 objects mostly useful when their lifetimesYou can use the HEAP storage engine in MySQL (I suppose you are using
MySQL). Created tables an their contents are stored in memory, read-
and write access to the tables would be much more effective than
reading large session files or to storing data in MyIsam or InnoDB
storage engines.

Regards,
purcaholic

On 31 Aug, 12:13, purcaholic <purcaho...@googlemail.comwrote:That doesn't really answer the OPs question - he could store the
session data in a HEAP table or ramdisk - but storing the underlying
data in a HEAP would be really stupid.

OP: Storing the data in the session means that even although larger
amounts are retained, it's all read in one go - if you have to
recreate the objects at runtime you'll be making one or multiple calls
to the database. But that's at the risk of the copied data not being
current.

You have to decide based on the frequency of updates and how much of
the data will actualy be required at runtime (there's not much point
storing hundreds of objects in the session if you only use, a couple
in each script.

C.

DigitalDave wrote:Yes, objects are quite useful. It's all in how you design your object.
For instance, it's not necessary to have a copy of the teacher object
for each student - only a way to get to the teacher object.

But I don't store large amounts of data in the session like that. I
just query the database when it's needed. It's not required on every
page, and if it is required that often, chances are it's already in the
database cache, anyway.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

You can store IDs instead of real objects in session, and have a
function like "Load_Object_From_Session()" and
"Save_Object_To_Session()" to operate them - stored in shared memory
or cache storage (PHP-APC cache can provide this, see
http://www.php.net/manual/en/book.apc.php )

On Aug 31, 2:15*pm, DigitalDave <d...@noSpam.comwrote:

AqD wrote:(Top posting fixed)

A very bad idea. Object id's are only unique to the current script -
not across scripts. So now you have multiple objects with the same id
in shared memory. Additionally, you will need to keep some catalog of
what's in shared memory. And using shared memory would be very insecure.

P.S. Please don't top post.



--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 2008-08-31 06:06:05 -0700, Jerry Stuckle <jstucklex@attglobal.netsaid:
That's exactly what we did -- we stored a reference to the teacher
object in each student object (aggregation.) But what we found upon
examining the temp file created by the session, was redundant teacher
data.
It wasn't large amounts of data in these objects. It was just redundant
objects stored in the session temp files.

But thanks for the idea that I'm beginning to get that objects aren't
useful between pages if there is composition or aggregation between
classes.

DigitalDave wrote:I didn't say keep a reference to the teacher object - I said have a way
to get to the teacher object. Such as an id to the object, etc.
Which you wouldn't have had had you not stored a reference to the
teacher object in your student variable.
Objects are very useful between pages.

But this has nothing to do with objects. If ANY variable is a
reference to something else, storing the variable in the session stores
whatever it refers to. That's the only way it can work.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sep 1, 8:46*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:An object itself has no ID. It's up to him to decide what the ID
should be (he has to implement the Save/Load functions by himself).
The uniqueness depends on his implementation.
is not true.
1.He can use APC cache instead of dealing shared memory by himself.
2.Shared memory or APC cache can only be as insecure as data in
session files or databases. It doesn't matter.

AqD wrote:Actually, objects do have resource id's. You just normally don't see
them. But I was referring to user-defined id's, based on your previous
comments. They are, however, still not unique across sessions.
Which again is a very bad idea. Session files are relatively secure.
APC cache is very insecure.

Plus now you're taking memory from the rest of the system. While it
could speed up this application, it can also slow down the entire
system, depending on how much you use. You also have to be concerned
that the memory gets cleaned up properly (what happens if you put
something in it but the user never progresses to the next page?). That
requires more work - which cuts into the script performance.

Your answer is not a good one at all. There are many more problems with
it than it solves.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sep 2, 8:36*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:As I said it's up to the OP to implement an unique ID across sessions.
I'm NOT telling him the details - but only a direction.
ROFL!

You do know PHP session files are stored as plain text? How could it
be any more secure than APC cache, which is also stored in temp file
in un-encrypted format?

If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
1.Obviously you don't know about APC at all. It uses temp files just
like session.
2.Memory cache systems like memcache always provide some kind of
expiration/cleanup mechanism.
Your opinions on my answer are quite funny :P

Your "problems" are the problems encountered when somone tries to
implement the cache system by himself - but I'm NOT telling him to do
this. Just pick up some existing cache system - and if it has any of
the problems you mentioned, find another one.

AqD wrote:Because you obviously don't understand how things work. The user
doesn't directly read/write to the session file like he does the APC
cache. Any process can easily screw up the APC cache. It takes work to
do it in the session file.

I didn't say session files were secure. I said APC cache is much less
secure - and I stand by my statement.
Yes, I do know about APC. And it also uses memory. Plus, you have to
figure out just when to expire the cache. And all kinds of other
things. And BTW - it is also slower than sessions.

In this case, APC cache is a solution looking for a problem.
You are so hung up on APC cache that you don't recognize its limitations.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sep 5, 7:39*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:So? Why would this be a problem? Any process can write to session
storage too.
Session isn't slower or faster. Session is the API not implemetation.

The point of using cache rather than session and to setup expiration
information etc, is simply because it's more flexible - because it's
not bound by session scope.

And it doesn't have to be APC cache.
Then the OP could replace APC cache with other cache systems.
It's true I don't recognize its limitations. But my suggestion is to
tell him to use some cache system. It doesn't have to be APC. And all
the problems you mentioned don't matter.

AqD wrote:They don't matter to you because you're so hung up on your cache that
you don't recognize the problems and limitations involved.

Sessions are used by millions of programmers - simply because they work
so well. I'm not saying they are the end-all to all problems. But they
work much better than trying to implement some crazy caching scheme.
The code is already built, tested, debugged and working. And it works well.

You can't say the same about caching mechanisms.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================