Никита Братский, покажите заголовоки запроса после login(), клиент должен отослать ту же самую JSESSIONID. если он ее отсылает, а на сервере нет сессии, значит сервер игнорит ее и нужно условный бряк ставить куда-нибудь в томкате и смотреть почему она пропала.
что-то с куками на стороне клиента?
клиент, получив session id в куках после login(), во второй раз не посылает ее на сервер, как следствие сервер создает новую сесию.
Аналог общей задачи: программно в несколько потоков подключаться к различным FTP серверам (которые могут не поддерживать пассивный режим) через промежуточный SSH-сервер.
По регламенту раз в месяц, но на многих инсталляциях. Пользователи сильно жалуются, что операция выполняется слишком долго и им приходится постоянно ждать по 30 минут (в реале задача немного сложнее описанной). Сейчас все будет проиходить за 8 минут максимум при первом импорте и за 2-3 минуты при всех последующих обновлениях.
Взял postgresql. Индексов в таблице на колонке deleted нет. Просмотр 2 млн строк действительно занимает секунды. С update сложнее. Я нашел причину столь долгой работы update-запроса. После каждого update-запроса размер таблицы увеличивается, план запроса сильно ухудшается, время запроса сильно увеличивается. На таблице вначале (после ее оптимизации) update-запрос выполнился за 40сек, потом за 2 минуты, потом за 4.5 минуты, тут еще запускается autovacuum (автоматическая оптимизация таблицы), которая тормозит все запросы к таблице. Все последующие запросы выполнялись за 4.5 минуты, autovacuum работает, видимо.
Данные в файле чаще всего не изменяются, обычно появляется 1000 новых строк, 1000 строк обновятся, 1000 строк удаляются. В вашем случае каждый раз придется весь файл записывать во временную таблицу, а в моем только те данные, которые реально изменяются (около 3000 строк), на практике это намного быстрее получается.
поправка: память O(1) будет если не грузить таблицу из файла в память, а отсортировать ее на диске с помощью mergesort. Получается, можно хоть миллиардные таблицы так синхронизировать.
1. Да, в Arktos варианте с deleted флагом так же можно сделать, согласен. Чую только проблемы со скоростью будут, ведь запрос на проставление всем строкам флага deleted по сути изменит почти все «хорошие» строки в таблице. В варианте с map «хорошие» строки не трогаются и по факту все последующие обновления происходят очень быстро.
2. С одной temp таблицей тоже отличная идея! Замерю время. Только все последующие обновления будут требовать вставки всех значений из файла во временную таблицу. В варианте с map, вставляются только реально те строки, которые нужно удалить/обновить/добавить.
Загрузили одну строчку, провели синхронизацию. Как? Запрос в базу для каждой загруженной из файла строки? Получится 2000000 запросов. Долго.
С хеш-таблицами сейчас так: грузим весь файл в map. Потом просматриваем таблицу из базы по K элементов (один селект, который грузит в память не всю таблицу, а по K строк). Для каждой строки смотрим в map по id, удаляя из него просмотренный элемент. Если нету, то во временную таблицу temp_delete сбрасываем id строки, если есть и значения в колонках не равны, то строку из map сбрасываем во временную таблицу temp_update. Оставшиеся в map строки — новые, добавляем из во временную таблицу temp_insert. Потом выполняем три запроса:
1. update mytable set deleted=1 from temp_delete t on t.id=mytable.id
2. update mytable set a=t.a, b=t.b, c=t.c from temp_update t on t.id=mytable.id
3. insert into mytable (a,b,c) values (select a,b,c from temp_insert)
итого: 1 sql запрос к таблице + куча запросов к временным таблицам (но они все типа insert batch, и во временных таблицах нет никаких индексов, кроме pk, поэтому достигается 10000запросов/сек) + 3 последних запроса, которые тоже быстрые, так как индексы в mytable обновляются только 1 раз, по времени уходит где-то 5 минут.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
