Вы не можете оставлять посты и комментарии еще 30 минут
19:18
Программирование:  
аноны, помогите пожалуйста. столкнулся с такой проблемой, что нигде нету гайдов нормальных по использованию пула соединений для jdbc api. ни в гугле, не в юубе ни чего нет. может есть у кого ссылка с подробным использованием. спасибо
19:24
 
Ох уж эти страдания жабаблядей! Как же хорошо что в свое время я бросил это говно и перешел на .NET.
21:08
[ОП]  
аминь, братан. сам дотнетчу. но в шараге дали задание по кроссплатформенной разработке
22:12
 
Не знаю как ты искал, первый результат в гугле http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html
23:08
[ОП]  
да там хуйпомешь что к чему. почему у джавы такая ебучая тупорылая документация
23:59
 
Есть отличное решение же.
09:44
[ОП]  
ой, ну вот только давайте вот тут без этого вот, пожалуйста. я ведь еще только учусь, и учусь дистанционно. препод скинул задания без каких-либо методичек и ебись как хочешь. БЫли бы гайды номальные где все структурировано объясненно я бы хуй куда написал. поэтому, не стукайте!
13:50
 
<div class="quote">пула соединений для jdbc api. ни в гугле, не в юубе ни чего нет</div> Подозреваю, что твоя проблема в некорректной постановке вопроса, ты искал несуществующую вещь, и вполне логично ничего не нашел. Непосредственно JDBC как таковом нет встроенного connection pool'а, который ты можешь использовать искаропки в голом джавовском приложении, т.е. в приложении, которое исполняется вне контейнера (Tomcat, JBoss/WildFly, WebLogic, Jetty и тому подобных) и не использует никаких сторонних библиотек. Я не знаю, что у тебя конкретно за задание и какие к нему требования, но думаю, что один из трех вариантов ниже попадает под твой случай: 1. Тебе надо написать какое-то J2EE приложение. Это подразумевает, что оно исполняется в контейнере. Во всех контейнерах есть connection pool'ы, обычно они конигурируются в настройках контейнера, а само твое приложение использует пул соединений, не подозревая об этом: DataSource ds = (DataSource) new InitialContext().lookup("jdbc/MyDB"); Connection conn = ds.getConnection(); To есть conn будет уже соединением из пула. В любом случае смотри документацию к своему контейнеру. Скажем, если это Tomcat, то тебе сюда: http://tomcat.apache.org/tomcat-8.5-doc/jdbc-pool.html 2. Тебе нужно написать J2SE приложение, использовать контейнеры ты не можешь или не хочешь по какой-то причине (даже встроенный Tomcat или Jetty), но ты можешь использовать сторонние библиотеки. В этом случае ты скорее всего будешь использовать что-то вроде C3P0, HikariCP или Apache DBCP. Всё крайне примитивно, например в случае с C3P0: ComboPooledDataSource ds = new ComboPooledDataSource(); ds.setDriverClass("org.postgresql.Driver"); ds.setJdbcUrl("jdbc:postgresql://localhost/MyDB"); ds.setUser("op"); ds.setPassword("huj"); ds.setMinPoolSize(10); ds.setAcquireIncrement(10); ds.setMaxPoolSize(50); Connection conn = ds.getConnection(); 3. У тебя задание самому написть пул соединений, или ты по каким либо причинам не можешь использовать никаких сторонних библиотек. В этом случае гугли object pool design pattern. <div class="quote">почему у джавы такая ебучая тупорылая документация</div> Мир несовершенен, но ты крепись. Главное, что ты, студент, умён и совершенно не ебуч.
19:16
 
Задание запилить приложение для работы с бд реализуя паттерн дао, работа с бд реализуется через пул соединений. Т.е. если я правильно понял, я в idea запиливаю java ee app и у меня автоматом соединение с бд идет через пул соединений, так?
11:22
 
<div class="quote">если я правильно понял, я в idea запиливаю java ee app и у меня автоматом соединение с бд идет через пул соединений, так?</div> Не думаю. Без понятия, что делает IDEA c JavaEE проектами, никогда не пользовался ей, но вряд ли она тебе сама запилит контейнер, а главное, сконфигурирует его. В любом случае, для того, чтобы из своего J2EE приложения ты мог сделать вот это: DataSource ds = (DataSource) new InitialContext().lookup("jdbc/MyDB"); тебе нужно этот "jdbc/MyDB" определить в качестве ресурса этого контейнера. Обычно это делается в конфигурационном XML, пройди по ссылке которую я давал выше и посмотри как это делается в Tomcat'е. <div class="quote">Задание запилить приложение для работы с бд реализуя паттерн дао, работа с бд реализуется через пул соединений.</div> Если это всё, и никаких пояснений больше нет, то задание довольно мутное. Не понятно, что от вас хотят, чтобы вы сами писали реализацию пула, или можно использовать готовую. Будем считать, что акцент тут на том, чтобы научить пользоваться DAO который вообще-то не нужен, и соответственно, с пулами велосипедов изобретать не надо. Посмотри на пикрел и качни архив от сюда: http://rgho.st/6rWs6NhMH - там свежая вишня, плюс бонусом я тебе запилил работающий хеллоуворлд с DAO и пулом соединений от C3P0.
12:01
 
братан, скинь на http://gist.github.com/ а то я параноик пул соединений уточнил у препода, говорит можно готовым ползоваться или самим написать. а чего дао не надо? это же норм практика разделять слой доступа даных/бтзнесслогика/ интерфейс, тот же паттерн мвц
16:37
 
Не, на гист же нельзя структуру директорий залить. От DAO попахивает конкретным одлфажеством, времен EJB 2.0, кода entity beans были таким уродством, что страшно вспомнить. Сейчас же в большинстве случаев JPA предпочтительней. Если есть задача использовать типы разные источников данных (DB, XML и т.д.) для одних и тех же объектов, тогда DAO норм.
22:12
 
спсибо за код. раз уж ты бывалый джавадевелопер подскажи где лучше кодить, а то я идею скачал чисто на шару. норм там? и еще пару вопросов: 1. мне надо будет по заданию пилить интерфейс на javafx, могу я к этому приложению прикрутить томкэт что бы использовать томкэтовский пул соединений? или к нему надо будет лучше c3po? 2. Надо ли в дао паттерне, когда создаешь классы сущностей из бд, в них указывать вторичные ключи как поле класса, если надо то в каком виде, создавать поле с числовым типом данных или поле с типом класса другой сущности. Например: таблица cliens с полем id, и вторичный ключ в таблице orders, где есть поле id_client. В описании модели данных в классе class Order { private integer id; private string name; ... private integer id_client; } или class Order { private integer id; private string name; ... private Client client; } как правильнее будет?
01:09
 
1. JavaFX - это из Java SE, непосредственно для JavaFX контейнеры не нужны. Обычно Томкат имеет смысл использовать, если приложению нужен web-интерфейс, ну или хотя бы что-то типа RESTful API. И потом, идеология контейнеров несколько иная: ты не прикручиваешь томкат к приложению, а скорее наоборот, "прикручиваешь" свое приложение к томкату. То есть ты пакуешь свое приложение особым образом в .war архиве, копируешь его в директорию приложений томката, а он уже его поднимает и исполняет. При этом таких независимых приложений в одном томкате может быть несколько. Можно, конечно, поступить наоборот, т.е. не стандартно. Tomcat и Jetty доступны кроме всего прочего в варианте embeddable, их можно особым образом прикрутить с приложению в виде библиотеки. Но делать это только ради пула соединений с БД - это, скорее, как из пушки по воробьям. Проще использовать что-то более легкое и специализированное, вроде того же C3P0 или HikariCP. 2. Вообще-то DAO паттерн не обязывает создавать классы сущностей, повторяющих структуру сущностей БД, это не JPA и не ORM. Он лишь подразумевает создание интерфейсов, описывающих логику работы с данными из внешних хранилищ (например, "создать заказ", "найти все заказы по владельцу", "вернуть список всех заказов, находящихся в процессе выполнения" и т.д.), и затем имплементации этих интерфейсов для каждого типа хранилища (RDBMS, файловая система, NoSQL БД). При этом гипотетический класс Order может иметь мало общего с гипотетической таблицей БД orders. Кроме того, класс, если он используется где-то за пределами имплементации DAO интерфейса, не должен включать в себя никаких специфических фич какого-то конкретного типа хранилища: например, целочисленные вторичные ключи имеют смысл в RDBMS, но скорее всего не имеют никакого смысла в NoSQL БД. То есть это ломает абстракцию, которую DAO паттерн старается реализовать. Поэтому предпочтителен второй вариант (private Client client), а интерфейсы DAO, которые конструируют класс Order, должны позаботится о корректном проставлении всех ссылок на другие объекты. Собственно, это один из моментов, почему JPA предпочтительней DAO, там это делается автоматически.
12:56
 
в интернетах нашел такой пример реализации дао для внешнего ключа. как он можно юзать?
00:49
 
В целом годная статья как раз как иллюстрация тезиса "DAO ненужен". Автор пытается тупо отзеркалить таблицы БД в классы Java, и в результате получает очень неэффективный (см. первый же коммент к статье) и довольно уродливый многословный код. Так делать не надо, надо просто использовать JPA вместо DAO в таких случаях. DAO должен быть крайне минималистичным. Его проектирование должно начинаться с бизнес логики приложения, а не структуры БД. Если можно обойтись без простого мапирования таблицы в класс, а ограничиться высокоуровневыми методами бизнес логики - отлично, код будет простой и эффективный. Если же всё таки нужно иметь в джавосвких классах зеркало таблиц БД, то тогда желательно: 1. Приготовиться есть кактусы, 2. Рассмотреть приемлемость "ленивой" загрузки зависимостей, 3. Рассмотреть возможность объединения паттернов DAO и что-то типа Flyweight, т.е. кешировать объекты, чтобы при восстановлении зависимостей не ходить каждый раз заново в БД и не создавать новый объект, а возвращать объект их кэша. При этом надо следить, чтобы объекты создавались только внутри этого DAO+Flyweight, а также чтобы все обновления проходили через него же, чтобы поддерживать кэш в актуальном состоянии (и это при условии, что только одна копия одного этого приложения может что-то менять в базе). По сути дела всё выливается в написание своего аналога JPA, не всего его функционала, конечно, но по крайней мере некого его подмножества. Только вот вопрос - ради чего?
09:12
 
так а каким должен быть дао? ведь во всех примерах показано, что надо создавать классы сущностей бд. если не сложно, опиши структуру пакетов и классов для норм дао.