By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,706 Members | 1,105 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,706 IT Pros & Developers. It's quick & easy.

How best to use php5 objects between pages?

P: n/a
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?

Aug 31 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
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?
You 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
Aug 31 '08 #2

P: n/a
On 31 Aug, 12:13, purcaholic <purcaho...@googlemail.comwrote:
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?

You 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
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.
Aug 31 '08 #3

P: n/a
DigitalDave wrote:
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?

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.
js*******@attglobal.net
==================

Aug 31 '08 #4

P: n/a
AqD
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:
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?
Sep 1 '08 #5

P: n/a
AqD wrote:
On Aug 31, 2:15 pm, DigitalDave <d...@noSpam.comwrote:
>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?


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 )
(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.
js*******@attglobal.net
==================

Sep 1 '08 #6

P: n/a
On 2008-08-31 06:06:05 -0700, Jerry Stuckle <js*******@attglobal.netsaid:
DigitalDave wrote:
>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?

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.
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.
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.
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.
Sep 1 '08 #7

P: n/a
DigitalDave wrote:
On 2008-08-31 06:06:05 -0700, Jerry Stuckle <js*******@attglobal.netsaid:
>DigitalDave wrote:
>>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?

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.

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.
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.
>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.

It wasn't large amounts of data in these objects. It was just redundant
objects stored in the session temp files.
Which you wouldn't have had had you not stored a reference to the
teacher object in your student variable.
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.
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.
js*******@attglobal.net
==================

Sep 2 '08 #8

P: n/a
AqD
On Sep 1, 8:46*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqD wrote:
*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)
*>

(Top posting fixed)

A very bad idea. *Object id's are only unique to the current script -
not across scripts.
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.
>*So now you have multiple objects with the same id
in shared memory.
is not true.
>*Additionally, you will need to keep some catalog of
what's in shared memory. *And using shared memory would be very insecure.
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.
Sep 2 '08 #9

P: n/a
AqD wrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqD wrote:
> 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)

(Top posting fixed)

A very bad idea. Object id's are only unique to the current script -
not across scripts.

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.
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.
> So now you have multiple objects with the same id
in shared memory.

is not true.
> Additionally, you will need to keep some catalog of
what's in shared memory. And using shared memory would be very insecure.

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.
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.
js*******@attglobal.net
==================

Sep 2 '08 #10

P: n/a
AqD
On Sep 2, 8:36*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
*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)
(Top posting fixed)
A very bad idea. *Object id's are only unique to the current script -
not across scripts.
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.

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.
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.
>
*So now you have multiple objects with the same id
in shared memory.
is not true.
*Additionally, you will need to keep some catalog of
what's in shared memory. *And using shared memory would be very insecure.
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.

Which again is a very bad idea. *Session files are relatively secure.
APC cache is very insecure.
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.
>
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.
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 answer is not a good one at all. *There are many more problems with
it than it solves.
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.
Sep 5 '08 #11

P: n/a
AqD wrote:
On Sep 2, 8:36 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
>>On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
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)
(Top posting fixed)
A very bad idea. Object id's are only unique to the current script -
not across scripts.
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.
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.

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.
>>> So now you have multiple objects with the same id
in shared memory.
is not true.
Additionally, you will need to keep some catalog of
what's in shared memory. And using shared memory would be very insecure.
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.
Which again is a very bad idea. Session files are relatively secure.
APC cache is very insecure.

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?
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.
If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
>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.

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.
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.
>Your answer is not a good one at all. There are many more problems with
it than it solves.

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.
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.
js*******@attglobal.net
==================

Sep 5 '08 #12

P: n/a
AqD
On Sep 5, 7:39*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 2, 8:36 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
*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)
(Top posting fixed)
A very bad idea. *Object id's are only unique to the current script -
not across scripts.
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.
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.
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.
>>*So now you have multiple objects with the same id
in shared memory.
is not true.
*Additionally, you will need to keep some catalog of
what's in shared memory. *And using shared memory would be very insecure.
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.
Which again is a very bad idea. *Session files are relatively secure..
APC cache is very insecure.
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?

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 workto
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.
So? Why would this be a problem? Any process can write to session
storage too.
>
If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
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.
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.

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.
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.
>
In this case, APC cache is a solution looking for a problem.
Then the OP could replace APC cache with other cache systems.
>
Your answer is not a good one at all. *There are many more problems with
it than it solves.
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.

You are so hung up on APC cache that you don't recognize its limitations.
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.
Sep 8 '08 #13

P: n/a
AqD wrote:
On Sep 5, 7:39 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
>>On Sep 2, 8:36 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
> 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)
>(Top posting fixed)
>A very bad idea. Object id's are only unique to the current script -
>not across scripts.
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.
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.
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.
> So now you have multiple objects with the same id
>in shared memory.
is not true.
> Additionally, you will need to keep some catalog of
>what's in shared memory. And using shared memory would be very insecure.
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.
Which again is a very bad idea. Session files are relatively secure.
APC cache is very insecure.
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?
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.

So? Why would this be a problem? Any process can write to session
storage too.
>>If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
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.
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.
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.

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.
>In this case, APC cache is a solution looking for a problem.

Then the OP could replace APC cache with other cache systems.
>>>Your answer is not a good one at all. There are many more problems with
it than it solves.
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.
You are so hung up on APC cache that you don't recognize its limitations.

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.
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.
js*******@attglobal.net
==================

Sep 8 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.