Сеансовые объекты без сохранения состояния по сравнению с бобами сессии Singleton
Если у вас есть одинаковые столбцы во всех файлах csv, вы можете попробовать код ниже. Я добавил header=0, чтобы после чтения csv первая строка могла быть назначена как имена столбцов.
path =r'C:\DRO\DCL_rawdata_files' # use your path
allFiles = glob.glob(path + "/*.csv")
frame = pd.DataFrame()
list_ = []
for file_ in allFiles:
df = pd.read_csv(file_,index_col=None, header=0)
list_.append(df)
frame = pd.concat(list_)
3 ответа
@Stateless позволит вам иметь несколько готовых копий для обработки в JVM (насколько позволяет память и размер пула), где @Singleton содержит только одну копию в JVM, даже если одна может поддерживать несколько параллельные потоки, работающие против него.
С точки зрения производительности @Singleton было бы лучше, при условии, что используемые им ресурсы обеспечивают длительный доступ. Однако в распределенной среде иногда случаются плохие вещи, например, ссылки на базу данных или сеть могут не работать.
С бином @Stateless доступ более короткий. Кроме того, в случае сбоя он просто возродится и попытается установить новое соединение с ресурсом. Если что-то происходит в одноэлементном режиме, то это единственный, который обрабатывает его, не требуя перезапуска приложения, потому что @PostConstruct вызывается только один раз для JVM.
Я предпочел бы немного отказоустойчивости по сравнению с производительностью для большинства ситуаций, особенно в системах, которые я не контролирую.
вам следует обратиться к Singleton, если у вас есть какой-либо ресурс, который будет оставаться постоянным во всем приложении. Как загрузка некоторых данных из какого-либо файла или справочных данных, которые не будут меняться в течение жизненного цикла приложения. в противном случае, перейдите на SLSB. Недостаток SLSB заключается в том, что будет создано несколько объектов, следовательно, будет занято больше памяти.
Я бы выбрал Stateless - сервер может генерировать множество экземпляров фасоли и обрабатывать входящие запросы параллельно.
Одиночка звучит как потенциальное узкое место - значение по умолчанию @Lock(WRITE) @Lock(WRITE), но может быть изменено на @Lock(READ) для фасоли или индивидуальных методов.
.