Liferay 6.1 CounterLocalService Which tables use "counter" vs class

[Danny Stevens, modificado 11 Anos atrás.]

CounterLocalService is used to generate the surrogate keys for Liferay's entities. Some use the generic counter, others specify their class name as the counter name.

Can anyone provide a list of which table uses which for Liferay 6.1?

The use case for this question is explained at primary key clash with records inserted to DB outside of service layer?

[edit]
I'm working my way through the code to find how CounterLocalService instance are injected into the various persistant layer classes. Its a bit slow going but I will return here when I have discovered anything that helps answer my own question.
[/edit]
[edit date="2012-09-11"]

Warning! Warning, Will Robinson!

We have a sharded database running in mySQL. Each shard has its own Counter table. None of them are used!

I searched and searched and discovered that in this configuration the counter data is stored in data/hsql/lportal.log. The counters are run as an in-memory database table which is occasionally saved to this file. This file is a critical part of your database and must be included in system back ups and synchronised with your database. If it is lost or gets out of synch you may have serious problems with your system because of clashing primary keys.
[/edit]
[edit date="2012-09-12"]

If you do not want to have the counters stored in HSQL when using shards then you must still define jdbc.default in your portal-ext.properties. If you do not want to call your default shard "default" you may still name it as you wish and have jdbc.default point to the same data source.

In the shard documentation it seems as though the use of jdbc.default is arbitrary, since there is a property called shard.default.name. If, as I did, you define a default shard as something like jdbc.shard00, with shard.default.name=shard00 and do not define jdbc.default, then everything works just as you would expect with the one exception to do with the counter records.

So here are the snippets for my final set up

jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost/db00?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username= ****
jdbc.default.password= ****

jdbc.shard00.driverClassName=com.mysql.jdbc.Driver
jdbc.shard00.url=jdbc:mysql://localhost/db00?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.shard00.username= ****
jdbc.shard00.password= ****

jdbc.shard01.driverClassName=com.mysql.jdbc.Driver
jdbc.shard01.url=jdbc:mysql://localhost/db01?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.shard01.username= ****
jdbc.shard01.password= ****

..etc to shard79

shard.available.names=shard00,shard01, ..etc to shard79
shard.default.name=shard00
shard.selector=com.liferay.portal.dao.shard.ManualShardSelector

I beleive shard.available.names is no longer needed. However I have kept it anyway. Note that default does not appear in this list.
[edit]

[Brian Kim, modificado 11 Anos atrás.]

I searched and searched and discovered that in this configuration the counter data is stored in data/hsql/lportal.log. The counters are run as an in-memory database table which is occasionally saved to this file. This file is a critical part of your database and must be included in system back ups and synchronised with your database. If it is lost or gets out of synch you may have serious problems with your system because of clashing primary keys.

It's been a while since I've dug into the code myself, but I'm pretty sure you shouldn't be looking in the HSQL folder if you're using MySQL.

[Danny Stevens, modificado 11 Anos atrás.]

Brian Kim:

I searched and searched and discovered that in this configuration the counter data is stored in data/hsql/lportal.log. The counters are run as an in-memory database table which is occasionally saved to this file. This file is a critical part of your database and must be included in system back ups and synchronised with your database. If it is lost or gets out of synch you may have serious problems with your system because of clashing primary keys.

It's been a while since I've dug into the code myself, but I'm pretty sure you shouldn't be looking in the HSQL folder if you're using MySQL.

You would think so

However, in running Liferay 6.1 ce ga1, with 10 shards, the counter table is not updated in any shard. Instead the file I indicated above is updated for counter information. Other database changes do appear in the appropriate mySQL database however.

[Brian Kim, modificado 11 Anos atrás.]

I did say that it has been some time since I've looked into it.

In any event, I'll see if I can verify with our engineers whether it is supposed to work this way.

[Michael C. Han, modificado 11 Anos atrás.]

The counter mechanism uses a separate datasource than the normal Liferay portal datasource. This is done to prevent potential resource locking of the counter table. Most likely when you activated sharding, the counter data source was still using the default portal one as opposed to the appropriate sharded data source.

[Michael C. Han, modificado 11 Anos atrás.]

Btw see counter-spring.xml where the counter data source is configured. The shard-data-source-spring.xml doesn't override the counter data source configurations so you'll need to modify that accordlingly

[Danny Stevens, modificado 11 Anos atrás.]

Thanks Michael. You gave me the vital clue I have added further knowledge in my opening post.

Also, future readers may want to know that counter-spring.xml is in [liferay dir]\tomcat-7.0.23\webapps\ROOT\WEB-INF\lib\portal-impl.jar\META-INF\.

[Corné Aussems, modificado 11 Anos atrás.]

Hi Danny,

This thread interests me a lot, because, we suffer from very occasional duplicate keys on the counter table while running on multiple nodes.
I hope splitting the counter table to the expected different shard DB will overcome this.
Could you please share your configuration "counter-spring.xml" and "shard-data-source-spring.xml" to learn from?

Thanks in advance.

Corné