Java daemon

[sl@exabyte]

I gather that PHP daemon suffers from memory leak problem due to its garbage
collector mechanism.

Since java also adopts the garbage collector mechanism, would java daemon
suffers from the same memory problem ?

Thanks.

[David Lamb]

On 12/11/2012 9:17 AM, sl@exabyte wrote:
> Since java also adopts the garbage collector mechanism, would java daemon
> suffers from the same memory problem ?

There are several different ways to do garbage collection, so flaws in
one implementation have no bearing on what goes on with another.

The most common complaint that crosses implementations is the
unpredictability of when a gc happens, which can be a problem for a
program with serious real-time constraints. IIRC Java implementations
often have the gc run continuously and incrementally in a separate
thread, which evens out the effect.

[Arne Vajhøj]

PHP uses reference counting, which has some known problems (circular
references).

It is typical not a big problem in PHP due to everything going out
when request scope runs out.

(that of course does not cover native resources in extensions,
but Java does not do anything with those either)

There are many Java implementations and most of them support
multiple garbage collection algorithms, so it is difficult to say
what "Java" does.

But all the most popular uses some type of mark and sweep to
find what is still reachable and what is not.

That does not have the same problems as reference counting.

So assuming that you use a common Java implementation, then
you should not see the same problems as in PHP.

Arne

[sl@exabyte]

This is an interesting pointer/direction (I am new with java, but have done
quite some C/C++ on windows).

I have sort of given up hope on PHP daemon; one cannot touch its GC I
suppose. I am adamant to go C/C++; I have not done anything on Linux. I
suppose it would take too long a time to get it up and running (my target is
end of December 2012). So my next best option is java.

[Jim Janney]

Probably not: not all implementations of GC are equal, and you can't
generalize from one to another. For what it's worth, Twitter is in the
process of migrating from Ruby to Java due to problems with memory
management, and claims to be happy with the results:

http://www.theregister.co.uk/2012/11/08/twitter_epic_traffic_saved_by_java/

--
Jim Janney

[Lew]

Jim Janney wrote:

> "sl@exabyte" writes:
>> I gather that PHP daemon suffers from memory leak problem due to its garbage
>> collector mechanism.

More likely it suffers from a packratting problem - failure to release memory.

>> Since java also adopts the garbage collector mechanism, would java daemon
>> suffers from the same memory problem ?

Not the same problem, but you can force Java to hang on to object references long
past their usefulness, and eventually use up your available memory.

Idiomatic Java avoids this.

--
Lew

[Martin Gregorie]

On Mon, 12 Nov 2012 23:55:58 +0800, sl@exabyte wrote:

> I have sort of given up hope on PHP daemon; one cannot touch its GC I
> suppose. I am adamant to go C/C++; I have not done anything on Linux.
>

I've not done a lot with PHP, but haven't (so far) run into any
particular problems with the Apache/PHP combination under Linux.

> I suppose it would take too long a time to get it up and running (my
> target is end of December 2012). So my next best option is java.
>

Actual Linux installation is fairly fast: the last install I did (RedHat
Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about the
following times:

- 1.5 hours to d/l and burn a 3.6GB DVD ISO image, though the time it
takes depends on your broadband speed.

- around an hour for the actual install. Exactly how long this takes
depends on how much you customize the disk partitioning and the list
of packages you ant to install. If you select 'all packages' and
use two partitions (30 GB for root and the rest of the disk for /home)
you should complete the install in just under an hour.

- 1.5 hours to update all packages that changed since the ISO image was
built - partly dependent on broadband speed.

That should leave you with an installation that contains, among other
useful stuff, Apache, PHP, Python, Perl, C, C++, Open Java, PostgreSQL,
Mysql and Eclipse.

If you're happiest with a Windows-like desktop, specify XFCE as your
desktop. Additional configuration should be minimal. Apache and the
various languages and databases should run if you enable their daemons
because their default Fedora configurations are fairly sensible - thats
Apache and any databases you need. All the other essential daemons will
be enabled by default, including the firewall and the SELinux security
module.

If you're familiar with Unices at all, you should be off and running PDQ.
There's a good graphical editor (gedit) as well as vi and emacs.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[sl@exabyte]

Martin Gregorie wrote:
>>
> Actual Linux installation is fairly fast: the last install I did
> (RedHat Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about
> the following times:
>

>....

Acutally I mean the my c/c++ programming in Linux would probably take too
long a time to meet my target since I have done anything on Linux.
My server program has to process XML string and MySQL. I had a look at a
sample C program with MySQL API last night, it did not look that
intimidating. At this stage I am a bit encouraged to dip my little toe into
the Linux pool. But my programming experience tells me there are always
surprises. :-)

[Arne Vajhøj]

On 11/12/2012 4:35 PM, Lew wrote:
> Jim Janney wrote:
>> "sl@exabyte" writes:
>>> I gather that PHP daemon suffers from memory leak problem due to its garbage
>>> collector mechanism.
>
> More likely it suffers from a packratting problem - failure to release memory.

Reference counted GC has known problems even without packratting.

>>> Since java also adopts the garbage collector mechanism, would java daemon
>>> suffers from the same memory problem ?
>
> Not the same problem, but you can force Java to hang on to object references long
> past their usefulness, and eventually use up your available memory.
>
> Idiomatic Java avoids this.

And none of the common Java implementations use reference counting for GC.

Arne

[Arne Vajhøj]

On 11/12/2012 5:07 PM, Martin Gregorie wrote:
> On Mon, 12 Nov 2012 23:55:58 +0800, sl@exabyte wrote:
>> I have sort of given up hope on PHP daemon; one cannot touch its GC I
>> suppose. I am adamant to go C/C++; I have not done anything on Linux.
>>
> I've not done a lot with PHP, but haven't (so far) run into any
> particular problems with the Apache/PHP combination under Linux.

For the typical web page the request scope is sufficient to
avoid problems.

But a daemon is not a typical web page.

Arne

[Arne Vajhøj]

The MySQL C API is indeed rather easy to work with.

If you have worked with PHP nysql or mysqli extensions, then it
will be even easier.

Arne

[SL]

sl@exabyte wrote:

> Acutally I mean the my c/c++ programming in Linux would probably take
> too long a time to meet my target since I have done anything on Linux.
> My server program has to process XML string and MySQL. I had a look
> at a sample C program with MySQL API last night, it did not look that
> intimidating. At this stage I am a bit encouraged to dip my little
> toe into the Linux pool. But my programming experience tells me there
> are always surprises. :-)

A correction, the statement "...since I have done anything on Linux" should
read "...since I have not done anything on Linux".

[SL]

I did some google'ing on garbage collector (GC) in java and found that it is
a big and complicated topic.
Java programmer has no permission to invoke it directly, beside juggling its
settings to adjust its frequency of running and the type of collector to
run. Even then how the GC is invoked stilll lies beyond programmer's
control.

It gets me thinking.

Why bother with it (people in the finance trade especially) ? Are the
advantages so great over c/c++ ? If the answer is yes, I can only think that
the reason is portability. Otherwise forget about tweaking GC; go for C/C++;
programmer has full control over memory management, and it is faster than
java.

I hope my opinion does not ignite the ire of java people.

I do have a question on GC: how to run the GC continuously ? Create a
thread, do some memory juggling to induce the GC to run ?

[Peter Duniho]

On Tue, 13 Nov 2012 14:40:23 +0800, SL wrote:

> [...]

> Why bother with it (people in the finance trade especially) ? Are the
> advantages so great over c/c++ ? If the answer is yes, I can only think that
> the reason is portability. Otherwise forget about tweaking GC; go for C/C++;
> programmer has full control over memory management, and it is faster than
> java.
>
> I hope my opinion does not ignite the ire of java people.

Probably not. Most of the "Java people" are secure enough in their
knowledge that they are using the right tool for the job to not worry about
what some person grinding an anti-Java axe might have to say.

Fact is, a) it is not a foregone conclusion that explicit memory management
is faster than GC. It depends a lot on the implementation, and GC-based
memory management has certain scenarios where it wins (allocations are
practically free, and a generational collector can do very well speed-wise
when dealing with large numbers of short-lived objects.

There's a fair amount of overhead maintaining a C-style heap, incurred
during both allocation and deallocation of memory blocks. It's just that
the overhead is more deterministic than what you see in GC systems.

And b) speed is not always the first priority anyway. An inordinately
large proportion of bugs found in a C/C++ program are memory-related. The
managed environment found in languages like Java protects against these
bugs. Things such as invalid pointers and inaccessible blocks of allocated
memory (aka "leaks") are a thing of the past with a GC system.

A program that runs fast is nice, but if required to choose, I'd rather
have a program that runs correctly.

Pete

[SL]

Peter Duniho wrote:
>
> Probably not. Most of the "Java people" are secure enough in their
> knowledge that they are using the right tool for the job to not worry
> about what some person grinding an anti-Java axe might have to say.

>....
>

I have no axe to grind, Peter.

I have hardly programmed beyond "Helo World" in java. The above was just my
personal opinion, it could be very well wrong.

I am just hoping to learn some more esoteric facts about about java and
c/c++, which only people with a lot of experiece can give.

I remember what my former once said:

"Read about people's biograhy. They take a life time to attain their
achievements, and the reader takes 1 to 2 weeks to learn them. I don't think
there is a better deal."

[Arved Sandstrom]

[ SNIP ]

No ire on my part. I back up what Peter said (particularly with respect
to maintenance and reliability), and I'll add a few remarks of my own.

Think about why you'd want to invoke the Java GC yourself, and what that
would entail. You'd want to know *when* to do it - if you wrote the code
yourself to make that decision, and you were really good and really
experienced, it would probably look a lot like _existing_ code for some
GC or another. If you weren't that good then your code just wouldn't cut it.

By "code" I mean both the actual source and the GC parameters that you
can tune.

At first glance it might seem like this indirection - setting parameters
- removes a lot of control. That's not the case.

I'm not saying this is you - you already said it's not - but people who
assert that they can do better decision-making as to when to invoke a GC
run than the code that represents years of experience of GC specialists
strike me in the same vein as people who assert they can get better gas
mileage using manual stick than people who drive modern automatic
transmission cars. A very few people *can* do that - the majority (huge
majority) can't.

AHS

[David Lamb]

On 13/11/2012 1:40 AM, SL wrote:
> David Lamb wrote:
>> On 12/11/2012 9:17 AM, sl@exabyte wrote:
>>> Since java also adopts the garbage collector mechanism, would java
>>> daemon suffers from the same memory problem ?
>>
>> There are several different ways to do garbage collection, so flaws in
>> one implementation have no bearing on what goes on with another.

> Why bother with it (people in the finance trade especially) ? Are the
> advantages so great over c/c++ ? If the answer is yes, I can only think that
> the reason is portability. Otherwise forget about tweaking GC; go for C/C++;
> programmer has full control over memory management, and it is faster than
> java.

GC has several big advantages over programmer control, one of them being
how often programmers get things wrong. A bug-free GC can be written
once, by experts, tested thoroughly, then lives on not subject to bugs
introduced by thousands of programmers across the hundreds of packages
you might use in any one program.

You never get reuse of already-deallocated memory, a classic source of
segmentation faults.

You never get the most common forms of memory leak, forgetting to
deallocate and losing the last pointer to the allocated memory. Though
people can misprogram to have long-lived structures point to ones no
longer needed; dunno how common that is. Technically this does not count
as a "memory leak"; rather it's "keeping data around too long that you
can still free eventually".

A compactifying GC can also *speed up* memory allocation and *reduce*
heap footprint by reducing fragmentation.

[Martin Gregorie]

I've been picking it up from "Programming PHP" (O'Reilly). That doesn't
mention anything even vaguely resembling a PHP Daemon.

What is it?
If you have Apache, why would you need it?
Is it some sort of lightweight web server?

[Martin Gregorie]

On Tue, 13 Nov 2012 10:56:47 +0800, sl@exabyte wrote:

> Martin Gregorie wrote:
>>>
>> Actual Linux installation is fairly fast: the last install I did
>> (RedHat Fedora 17 on a dual 3GHz Athlon box with 4GB Ram) took about
>> the following times:
>>
>>....
>
> Acutally I mean the my c/c++ programming in Linux would probably take
> too long a time to meet my target since I have done anything on Linux.
>

So don't use them.

You'd have PHP (which you say you already know) and Apache, so move your
web pages and PHP scripts over and get hacking. The PEAR library is alive
and well under Linux too, so all the standard PHP add-ons, database
interfaces, etc. are there to be used.

> My server program has to process XML string and MySQL.
>

PHP can deal with XML and interface to MySQL, though why anybody would
use it when using PostgreSQL has more standardised SQL and is as easy to
install for the same price, is more than I can imagine.

If you don't have O'Reilly's "Programming PHP" in your library, maybe you
need a copy.


If, for some reason, you can't do everything you need with Apache, PHP
and PostgreSQL, most distros have Python, Perl and gawk awaiting your
pleasure.

Fedora has the Java OpenJDK 1.7 too.

[Arne Vajhøj]

You know what a daemon is.

Besides the web integration with Apache and IIS that accounts
for 99+% of PHP usage, then PHP also comes with a command line
utility.

So you can write a daemon in PHP and run it via the command line
utility.

Arne

[John B. Matthews]

In article <k7sq0e$poi$1...@news.albasani.net>, "SL" <sb5...@hotmail.com>
wrote:

> I do have a question on GC: how to run the GC continuously ? Create a
> thread, do some memory juggling to induce the GC to run ?

On my platform, the JVM automatically spawns several threads to
facilitate garbage collection, including one called "Concurrent
Mark-Sweep GC Thread," which runs at a moderately lower priority than
the event queue. The host's scheduler uses multiple cores (when
available) to balance the load in favor of the user. The overall effect
is that even "busy" programs remain responsive, and I rarely notice GC
unless I'm looking for it, say in a profiler.

IIUC, the exact number and names of threads is platform-dependent. You
can use jvisualvm, included with the JDK, to see a thread timeline; or
you can take a snapshot of running threads via `kill -SIGQUIT pid`.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Martin Gregorie]

On Tue, 13 Nov 2012 17:31:22 -0500, Arne Vajhøj wrote:

> You know what a daemon is.
>
> Besides the web integration with Apache and IIS that accounts for 99+%
> of PHP usage, then PHP also comes with a command line utility.
>
> So you can write a daemon in PHP and run it via the command line
> utility.
>

Thanks for the clarification. I thought you must have been talking about
some special PHP daemonising framework or library.

[Arne Vajhøj]

On 11/14/2012 4:33 PM, Martin Gregorie wrote:
> On Tue, 13 Nov 2012 17:31:22 -0500, Arne Vajhøj wrote:
>
>> You know what a daemon is.
>>
>> Besides the web integration with Apache and IIS that accounts for 99+%
>> of PHP usage, then PHP also comes with a command line utility.
>>
>> So you can write a daemon in PHP and run it via the command line
>> utility.
>>
> Thanks for the clarification. I thought you must have been talking about
> some special PHP daemonising framework or library.

Nope. Just not very good at explaining what I meant.

Arne

[Martin Gregorie]

Probably same here. I have written a batch-type program in PHP but would
probably not do it again because I think there are better languages for
that. This program walks a directory structure, generating thumbnails of
all the images it finds. Its companion (still in PHP under Apache)
generates menus if thumbnails on the fly. Its first cut generated the
thumbnails as needed, but that was deadly slow, hence the overnight batch
directory walker.

I ended up rewriting the thumbnail generating program in Java and dumping
the PHP version when I needed a non-trivial enhancement (the ability to
generate permanent HTML menu pages. As a bonus, the Java version is
significantly faster which is quite surprising considering its run is
fairly short - 2-3 seconds on a typical run when it finds nothing to do
in the 600+ directories it looks at.

[Arne Vajhøj]

The article is not very specific - "manage memory more efficiently" do
not tell much about the issues.

But other sources explain. Ruby do use mark and sweep like Java and
not ref count as PHP. But it has no generations and are global stop
during the entire GC. Which is not as good as modern Java GC's.

Arne

[Arne Vajhøj]

On 11/13/2012 4:50 PM, Martin Gregorie wrote:
> On Tue, 13 Nov 2012 10:56:47 +0800, sl@exabyte wrote:
>> My server program has to process XML string and MySQL.
>>
> PHP can deal with XML and interface to MySQL, though why anybody would
> use it when using PostgreSQL has more standardised SQL and is as easy to
> install for the same price, is more than I can imagine.

More users => better support.

And most of the non-standard SQL problems went away with
MySQL 4.1 and 5.0 back in 2005 and 2006.

Arne

[Arne Vajhøj]

On 11/13/2012 1:40 AM, SL wrote:
> I did some google'ing on garbage collector (GC) in java and found that it is
> a big and complicated topic.

It certainly is.

> Java programmer has no permission to invoke it directly, beside juggling its
> settings to adjust its frequency of running and the type of collector to
> run. Even then how the GC is invoked stilll lies beyond programmer's
> control.
>
> It gets me thinking.
>
> Why bother with it (people in the finance trade especially) ? Are the
> advantages so great over c/c++ ?

Yes.

GC is a lot better than manual deallocation for non realtime
usage as programmer tend to forget to deallocate resulting
in memory leaks.

And there are also other areas where the programmers end up
misusing the control that C++ provides you.

> If the answer is yes, I can only think that
> the reason is portability.

That is one reason but there are plenty of other.

> Otherwise forget about tweaking GC;

Yes. Because 99.999% of developers can not do a better job than what
the GC specialists has designed.

> go for C/C++;
> programmer has full control over memory management,

Which is a very good reason for not choosing C/C++ unless you
have special requirements like realtime, hardware interface or
kernel code.

> and it is faster than
> java.

That is not always the case.

> I do have a question on GC: how to run the GC continuously ? Create a
> thread, do some memory juggling to induce the GC to run ?

The GC should not run continuously - that would be very bad for
performance.

Arne

[markspace]

On 11/12/2012 10:40 PM, SL wrote:

> I do have a question on GC: how to run the GC continuously ? Create a
> thread, do some memory juggling to induce the GC to run ?

I haven't been following closely, so I don't know what version of Java
you're working with, but a web search for "java garbage collection
tuning" usually gives lots of good hits.

<http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html#available_collectors>

You probably want the parallel GC or the concurrent GC. And no, you do
not create a new thread or "juggle memory," you configure it externally
to your application.

Also, take a look at the System.gc() call, but DON'T USE THAT unless
you're sure you need it. The garbage collector is probably smarter than
you are about when and how to collect unused memory, frankly.

<http://stackoverflow.com/questions/2414105/why-is-it-a-bad-practice-to-call-system-gc>

[Martin Gregorie]

On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:

> And most of the non-standard SQL problems went away with MySQL 4.1 and
> 5.0 back in 2005 and 2006.
>

So, you're telling me its now ditched auto-incrementing fields and has
implemented sequences?

[Arne Vajhøj]

On 11/18/2012 8:05 PM, Martin Gregorie wrote:
> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>> 5.0 back in 2005 and 2006.
>>
> So, you're telling me its now ditched auto-incrementing fields and has
> implemented sequences?

No.

But then auto increment is also the standard (with IDENTITY
keyword though).

And it is also the most widely supported: MySQL,
SQLServer, DB2 etc..

PostgreSQL has it in the form of SERIAL (even though it is just
syntactic sugar for a sequence).

Sequences is really an Oracle and PostgreSQL proprietary thing.

MySQL are trying to converge towards standards not away from
standards.

Arne

[Lew]

Arne Vajhøj wrote:
> And most of the non-standard SQL problems went away with
> MySQL 4.1 and 5.0 back in 2005 and 2006.

TIMESTAMP remains non-standard.
http://dev.mysql.com/doc/refman/5.5/en/datetime.html
http://dev.mysql.com/doc/refman/5.5/en/timestamp-initialization.html

I am aware of no perfectly compliant SQL DBMS.

--
Lew

[Arne Vajhøj]

On 11/18/2012 11:10 PM, Lew wrote:
> Arne Vajhøj wrote:
>> And most of the non-standard SQL problems went away with
>> MySQL 4.1 and 5.0 back in 2005 and 2006.
>
> TIMESTAMP remains non-standard.
> http://dev.mysql.com/doc/refman/5.5/en/datetime.html
> http://dev.mysql.com/doc/refman/5.5/en/timestamp-initialization.html

Note that the closest to SQL TIMESTAMP is not MySQL TIMESTAMP
but MySQL DATETIME.

(the difference between standard and DATETIME is that DATETIME is
missing the fractional seconds and TZ)

> I am aware of no perfectly compliant SQL DBMS.

True.

But some stuff are worse than other.

Very old versions of MySQL was pretty bad. UNION was
added in 4.0, subqueries was added in 4.1 and views
was added in 5.0.

Arne

[jlp]

Le 18/11/2012 23:02, markspace a �crit :

If the OP uses a JVM Java HotSpot 7 ( Oracle or Open JDK) , he can take
a look to the G1 ( G first) garbage collector. It is an improve of the
CMS garbage collector. This garbage collector is more "Real Time" than
the others garbage collectors.

--
Cordialement
Jean-Louis Pasturel

[Martin Gregorie]

On Sun, 18 Nov 2012 20:41:19 -0500, Arne Vajhøj wrote:

> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>> 5.0 back in 2005 and 2006.
>>>
>> So, you're telling me its now ditched auto-incrementing fields and has
>> implemented sequences?
>
> No.
>
> But then auto increment is also the standard (with IDENTITY keyword
> though).
>
> And it is also the most widely supported: MySQL,
> SQLServer, DB2 etc..
>
> PostgreSQL has it in the form of SERIAL (even though it is just
> syntactic sugar for a sequence).
>
> Sequences is really an Oracle and PostgreSQL proprietary thing.
>

I haven't looked at the SQL standard for quite a while and thought
sequences were in it. My bad.

I have to say I like sequences a lot better than auto-incrementing fields
for one reason: you know what the unique value is before doing the
INSERT, which seems cleaner to me that doing the INSERT and then reading
the new row to find out what the auto-incremented value is.

In fact, for this exact reason I'd prefer do what I've had to do with
DBMSs that don't have either sequences of auto-incrementing: namely to
'fake' a sequence by updating a singleton row in a dedicated table rather
than use auto-increment.

Needless to say, this should also happen within an explicit commitment
unit and, of course, ymmv.

> MySQL are trying to converge towards standards not away from standards.
>

I'm pleased to hear it: SQL standards are A Good Thing.

[Arved Sandstrom]

On 11/18/2012 09:41 PM, Arne Vajhøj wrote:
> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>> 5.0 back in 2005 and 2006.
>>>
>> So, you're telling me its now ditched auto-incrementing fields and has
>> implemented sequences?
>
> No.
>
> But then auto increment is also the standard (with IDENTITY
> keyword though).
>
> And it is also the most widely supported: MySQL,
> SQLServer, DB2 etc..

Oracle has sequences, PostgreSQL has sequences, SQL Server has sequences
(now), DB2 has sequences...MySQL, I don't think so (I stand to be
corrected).

> PostgreSQL has it in the form of SERIAL (even though it is just
> syntactic sugar for a sequence).
>
> Sequences is really an Oracle and PostgreSQL proprietary thing.

Not anymore. Sequences were introduced into the SQL standard in 2003. As
you alluded to above, this version introduced identity columns (which
are considered to use an internal sequence generator).

> MySQL are trying to converge towards standards not away from
> standards.

No more so than anyone else.

> Arne

AHS

[Arne Vajhøj]

On 11/19/2012 7:32 PM, Martin Gregorie wrote:
> On Sun, 18 Nov 2012 20:41:19 -0500, Arne Vajhøj wrote:
>
>> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>>> 5.0 back in 2005 and 2006.
>>>>
>>> So, you're telling me its now ditched auto-incrementing fields and has
>>> implemented sequences?
>>
>> No.
>>
>> But then auto increment is also the standard (with IDENTITY keyword
>> though).
>>
>> And it is also the most widely supported: MySQL,
>> SQLServer, DB2 etc..
>>
>> PostgreSQL has it in the form of SERIAL (even though it is just
>> syntactic sugar for a sequence).
>>
>> Sequences is really an Oracle and PostgreSQL proprietary thing.
>>
> I haven't looked at the SQL standard for quite a while and thought
> sequences were in it. My bad.
>
> I have to say I like sequences a lot better than auto-incrementing fields
> for one reason: you know what the unique value is before doing the
> INSERT, which seems cleaner to me that doing the INSERT and then reading
> the new row to find out what the auto-incremented value is.

You don't read the row to find out what the generated key is.

You query the connection for what it is.

The function name is database specific, but JDBC encapsulate
it nicely via Statement getGeneratedKeys.

Arne

[Arne Vajhøj]

On 11/19/2012 7:38 PM, Arved Sandstrom wrote:
> On 11/18/2012 09:41 PM, Arne Vajhøj wrote:
>> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>>> 5.0 back in 2005 and 2006.
>>>>
>>> So, you're telling me its now ditched auto-incrementing fields and has
>>> implemented sequences?
>>
>> No.
>>
>> But then auto increment is also the standard (with IDENTITY
>> keyword though).
>>
>> And it is also the most widely supported: MySQL,
>> SQLServer, DB2 etc..
>
> Oracle has sequences, PostgreSQL has sequences, SQL Server has sequences
> (now),

In 2012. They have had identity auto increment since it was called
Sybase.

> DB2 has sequences...MySQL, I don't think so (I stand to be
> corrected).
>
>> PostgreSQL has it in the form of SERIAL (even though it is just
>> syntactic sugar for a sequence).
>>
>> Sequences is really an Oracle and PostgreSQL proprietary thing.
>
> Not anymore. Sequences were introduced into the SQL standard in 2003. As
> you alluded to above, this version introduced identity columns (which
> are considered to use an internal sequence generator).

????

SQL IDENTITY columns are used the same way as MySQL auto increment
not the same way as sequences in Oracle and PostgreSQL.

There must be something like a sequence behind it. But if it is not
visible and the usage is restricted to the auto increment way, then
that is implementation.

Arne

[SL@maxis]

On Tue, 20 Nov 2012 03:39:10 +0800, jlp <j...@jlp.com> wrote:

> If the OP uses a JVM Java HotSpot 7 ( Oracle or Open JDK) , he can take
> a look to the G1 ( G first) garbage collector. It is an improve of the
> CMS garbage collector. This garbage collector is more "Real Time" than
> the others garbage collectors.
>

I decide that I have windows c/c++ programming that I think I can get a
daemon in C to run by month-end, since my daemon deals with XML processing
and MySQL, and of course communicating over sockets.

Hope that you people are in the C/C++ Linux group, which I shall turn to
if I get stuck. :-)

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[Arved Sandstrom]

On 11/19/2012 09:22 PM, Arne Vajhøj wrote:
> On 11/19/2012 7:38 PM, Arved Sandstrom wrote:
>> On 11/18/2012 09:41 PM, Arne Vajhøj wrote:
>>> On 11/18/2012 8:05 PM, Martin Gregorie wrote:
>>>> On Sun, 18 Nov 2012 16:43:39 -0500, Arne Vajhøj wrote:
>>>>> And most of the non-standard SQL problems went away with MySQL 4.1 and
>>>>> 5.0 back in 2005 and 2006.
>>>>>
>>>> So, you're telling me its now ditched auto-incrementing fields and has
>>>> implemented sequences?
>>>
>>> No.
>>>
>>> But then auto increment is also the standard (with IDENTITY
>>> keyword though).
>>>
>>> And it is also the most widely supported: MySQL,
>>> SQLServer, DB2 etc..
>>
>> Oracle has sequences, PostgreSQL has sequences, SQL Server has sequences
>> (now),
>
> In 2012. They have had identity auto increment since it was called
> Sybase.

Hence my "(now)".

>> DB2 has sequences...MySQL, I don't think so (I stand to be
>> corrected).
>>
>>> PostgreSQL has it in the form of SERIAL (even though it is just
>>> syntactic sugar for a sequence).
>>>
>>> Sequences is really an Oracle and PostgreSQL proprietary thing.
>>
>> Not anymore. Sequences were introduced into the SQL standard in 2003. As
>> you alluded to above, this version introduced identity columns (which
>> are considered to use an internal sequence generator).
>
> ????
>
> SQL IDENTITY columns are used the same way as MySQL auto increment
> not the same way as sequences in Oracle and PostgreSQL.
>
> There must be something like a sequence behind it. But if it is not
> visible and the usage is restricted to the auto increment way, then
> that is implementation.
>
> Arne
>

Hence my wording "are considered to". IOW, the spec says that for
definitional purposes, identity columns are associated with an internal
sequence generator.

But it's separate from implementation details - the "notion" of an
internal sequence generator ("notion" being a word used in the spec) is
inherent in the definition of identity columns in the *specification*.
It is simply a useful abstraction, especially seeing as how sequences
were introduced in the same spec. There are both external SGs (the ones
we can create and configure) and internal SGs, the latter being
components of another schema object.

I think we all understand the difference between IDENTITY and (external)
sequences (the latter a la PostgreSQL or Oracle). One is inextricably
associated with a specific table, one is not.

AHS