> After changing/updating/fixing/etc the code now runs 100%
> reliable and fast! Code put into production yesterday and
> looking good!
That is good to hear!
-Leigh
~|
Want to reach the ColdFusion community with someth
> I'v now come across a code problem that I simply cannot understand
> what is happending here.
>
>
>
> The code is part of a cfc module that is behind a web-service.
> This is not inside a loop - just a normal cfc with a function that
> enter, process and returns data...
>
>
> The prob
I can't comment on whether for your app singleton is right or not. Just be
aware that in CF singleton is much more common than in Java, largely due to
the much higher object instantiation overhead.
Jaime
On Wed, Dec 9, 2009 at 3:28 PM, Andre Kapp wrote:
>
> Tks Leigh
>
> I changed all the vari
> > It pretty much looks like a singleton design!
>
> Yep. I think Jaime has it right. It looks like few (if any) of the
> variables set within the DAO's functions are VAR scoped. So they will
> automatically be placed in the shared "variables" scope. Since you are
> working with a singleton,
> but you'd have to find where
> the service is instantiated to be sure.
Based on the names, I took a leap of faith that it really is what it appears to
be ;-) But Jaime is right. You should verify it.
-Leigh
~|
Wan
> It pretty much looks like a singleton design!
Yep. I think Jaime has it right. It looks like few (if any) of the variables
set within the DAO's functions are VAR scoped. So they will automatically be
placed in the shared "variables" scope. Since you are working with a singleton,
those variab
Andre,
Yeah, looks like singleton, but you'd have to find where the service is
instantiated to be sure. Throw it back to the guys who wrote the code
anyway! They should be var scoping always.
Don't know about the classid. You can of course get the hashcode - see
http://www.compoundtheory.com/
> >Andre,
> >
> >Is this DAO a singleton? I notice the queries aren't var scoped. If
> this
> >is a singleton under load another thread could easily overwrite your
> >trans_insert variable in between issuing the query and logging the
> generated
> >key.
> >
> >Jaime
> >
> >
> >
> >>
> Tks Jaim
>Andre,
>
>Is this DAO a singleton? I notice the queries aren't var scoped. If this
>is a singleton under load another thread could easily overwrite your
>trans_insert variable in between issuing the query and logging the generated
>key.
>
>Jaime
>
>
>
>>
Tks Jaime.
I have traced the code back t
Andre,
Is this DAO a singleton? I notice the queries aren't var scoped. If this
is a singleton under load another thread could easily overwrite your
trans_insert variable in between issuing the query and logging the generated
key.
Jaime
On Tue, Dec 8, 2009 at 8:58 PM, Andre Kapp wrote:
>
>
Ok - changed the pk id field returned to the following:
Still the same issue.
Here is the complete cfc module sorry for it being a bit long...
Tks for all the feedback so far.
The problem is that the ID is returned correctly in the first place(first
cflog), but when the variable is referenced later on in the code, it has
changed (second cflog)!
The total big picture is:
One CF server running a program that generates 10 threads. Thes
> The ID that was generated is maintained in the server on a per-connection
> basis. This means that the value returned by the
> function to a given client is the first AUTO_INCREMENT value generated for
> most recent statement affecting an
> AUTO_INCREMENT column by that client. This value cann
> A single request won't necessarily keep the same connection, especially
> under load. So unless you use a transaction, it's entirely possible for the
> insert query to run on one connection, and the select last_insert_id() to
> run on another connection. See http://lagod.id.au/blog/?p=41
If yo
thanks Jaime, I'll make sure that I use cftransaction.
Andrew.
>Andrew G,
>
>But...:)
>
>A single request won't necessarily keep the same connection, especially
>under load. So unless you use a transaction, it's entirely possible for the
>insert query to run on one connection, and the select la
Andrew G,
But...:)
A single request won't necessarily keep the same connection, especially
under load. So unless you use a transaction, it's entirely possible for the
insert query to run on one connection, and the select last_insert_id() to
run on another connection. See http://lagod.id.au/blog
Andrew,
I can't help thinking the code you haven't shown is important. Are you
creating a CF thread? And are any of your variables in shared scopes?
Transactions and threads don't necessarily work the way you might expect.
There are lots of possibilites for cross-talk between threads, connectio
maybe not (wrong)...
The ID that was generated is maintained in the server on a per-connection
basis. This means that the value returned by the function to a given client is
the first AUTO_INCREMENT value generated for most recent statement affecting an
AUTO_INCREMENT column by that client. Th
> I was under the impression that Last_Insert_ID() in MySQL was the equilavent
> of Scope_Identity() in MSSQL.please correct me
> if I'm wrong.
You're wrong, I think. From the MySQL docs:
"For LAST_INSERT_ID(), the most recently generated ID is maintained in
the server on a per-connection b
I was under the impression that Last_Insert_ID() in MySQL was the equilavent of
Scope_Identity() in MSSQL.please correct me if I'm wrong.
Andrew.
> Last_insert_id does just that, gets the last inserted id.
> No matter who entered it.
> This means that under intense traffic, that select may
Last_insert_id does just that, gets the last inserted id.
No matter who entered it.
This means that under intense traffic, that select may not return the id
associated with that transactions action.
You should find the mysql equivalent to ScopeIdentity()
Or if you are using a newer version of c
21 matches
Mail list logo
