Java daemon

[Arne Vajhøj]

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]

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>

 

[Arne Vajhøj]

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]

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.

 

[Arne Vajhøj]

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 :

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>

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.

 

[Arved Sandstrom]

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]

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]

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


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]

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.

 

[Arved Sandstrom]

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

Hence my "(now)".

????

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