Ситуация такая:

Надо уметь считать всякие разные вызовы - вебсервисы, еджиби вызовы. Их много разных. Все в одном большом еаре(сейчас)
Все это прикручено аспектами, вопросов не возникает.
Вопрос в том чтоб быстро считать, аккумулировать и по шедулеру сливать статистику в базу(к примеру).

Счетчик будет выглядеть как ConcurrencyHashMap c AtomicInteger и обновляться по CAS'у

Возник вопрос где этот счетчик единообразно хранить. 

- Синглетон, конечно, хорош. 
И даже будет до определенного момента работать. Но как только класслоадеры расползутся - швах.
Шедулер стянет инфу счетчика из своего класслоадера и все. Остальные потеряются. 
Идей как пересчитать все класслоадеры, все счетчики в них и посчитывать данные - нету.
Вернее, выглядят они абсолютно безумными с т.з. ЕЕ (имхо)

- Есть отличная, шикарная вещь в 3.1 @Singleton
А именно bean management concurrency 
Но джибосс ее поддерживает начиная с 7-го :(
Мы мигрируем, но только на 6-й максимум :(

- Есть сугубо джибоссовская аннотация @Service для синглетона (интуитивно понятное название, не правда ли?  )
В доке ничего о конкарренси не сказано. Инет пестрит индусскими выводами "раз он синглетон - значит конкарренси ручками, ручками"

Заимплементил с ней пример.
Сотня клиентов, каждый валит по тысяче вызовов, порядочный классец должен был бы сломаться после двух параллельных counter++;
И побежать к плюс бесконечности.
Хрена с два. Строгие нолики на выходе.
Эта тварюка все-таки thread safe.




Итого :(
@Service мне вроде подходит. Но это будет преступлением практически все залочить на один классец с такой прямолинейной синхронизацией на одном мониторе.
Шаг влево-вправо - и вместо подсчета скорости мы получим обвал скорости и затык.

Рассматриваю варианты:

http://docs.jboss.org/ejb3/docs/reference/...extensions.html 
(поиском Test asynchTest = org.jboss.ejb3.asynchronous.Asynch.getAsynchronousProxy(test); )

Сунул асинхронный count - и забыл про него.


И второй вариант, стремный, но красивый:
Заюзать @Service и полагаться на то, что это никак не аукнется в ближайшее время (систему все равно никто еще не оптимизировал пока - страх и ужас начиная с отсутствия индексов).
Со временем, с выходом JBoss SOA 6  с JBoss AS 7 внутри - поднять вопрос о срочной миграции на него и засунуть @Singleton вместо @Service со своей синхронизацией.


Асинхронность вроде решает(не знаю что там с накладными расходами), но некрасиво - жуть.
@Service - тупо и в лоб. Чисто, красиво, по джибоссовским понятиям. Но синхронизировать сотни высоконагруженных(в будущем) методов и сервисов на единственном мониторе религия не позволяет.


ЗЫ: Самое паршивое что с еджиби работал года так 4 назад, ничего не помню, да и монструозность с очевидностью, особенно джибоссовская, вызывает приступы немотивированной агрессии   



Может я уткнулся в мысленный тупик? Посоветуйте незамутненным разумом что-то, а? 





Это сообщение отредактировал(а) chief39 - 23.8.2012, 19:09

Если совсем не получается, то может следует использовать UUID?

Эммм.. если бы я сказал что понял, я бы соврал 

Как, что и куда прикручивать? 


ЗЫ: Напутал с версиями, вроде бы будет 5 жбосс. Но гарантированно Ежибяки 3.0, не больше :(

Это сообщение отредактировал(а) chief39 - 23.8.2012, 23:39

Я имею ввиду, в данном случае, когда использование централизованного генератора уникальных идентификаторов неоправданно, можно использовать распределенный генератор. UUID - один из алгоритмов, позволяющих сделать это. 
В джаве это можно сделать так

Так мне считать надо, а не случайные числа генерить 


Вопрос решился бутылкой пива и мыслью "гляну-ка я еще разок":


должно выглядеть вот так


Я умудрился оставить стейтлесс и списать это на контейнерную конкарренси.

Теперь все отлично, кантер моментально сходит с ума при сотне клиентов 

Это сообщение отредактировал(а) chief39 - 26.8.2012, 00:23