|
|
发表于 18-4-2014 02:43 PM
|
显示全部楼层
披狼皮de羊 发表于 18-4-2014 02:39 PM 
这个 JDBC 。。新手的时候经常会 handgun 的。。我也是搞了很久才弄清楚
以前的新手通常都是那种 mistakes，不会用 pooling, 开了 connection 忘记关 ～
现在的鼓励他们去用 open source 的，还是 ORM 的 framework 就好了，省麻烦呵呵呵。。。。
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 03:02 PM
|
显示全部楼层
披狼皮de羊 发表于 18-4-2014 02:51 AM
如果 front end 的不请深资 programer 是有原因的。。比较容易教
也是有道理，
from known to unknown,
“老屎忽”是做不到的。。。
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 05:56 PM
|
显示全部楼层
卡螺丝 发表于 16-4-2014 03:38 PM
不是要说楼主的薪金多还是少，
现在的劳资市场真的没有3-4年前那么好景了。。
2010年在JS申请工作，
很赞同你的话。
反而现在样样起价，只有工钱没起
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 06:53 PM
|
显示全部楼层
|
你们在讨论的ｆｒｏｎｔ ｅｎｄ ｂａｃｋ ｅｎｄ是什么鬼来的？ |
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 07:11 PM
|
显示全部楼层
pcstory 发表于 18-4-2014 02:35 PM
呵呵呵 ～ 连基本工不好很难咯。。。。。。
不过我看过更好笑的。。。我新加坡第一份工的 senior... 那 ...
我也看過一個本地大型零售商的internal system的code
每個crud都會create一個hibernate的factory, 最死是login那邊沒關connection的
db那邊的設定大概是30~50個connections, 所以每次login不到, 他們就reboot
這project一開始是由一個senior級的人物開始寫的, 後來的1~2年由另一個也是senior級的接手, 沒有一點改進, 延續著前人的作風一個enchance下去.... |
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 07:18 PM
|
显示全部楼层
pcstory 发表于 18-4-2014 02:43 PM
以前的新手通常都是那种 mistakes，不会用 pooling, 开了 connection 忘记关 ～
现在的鼓励他们去用 ...
老手就算不會, 什麼framework都救不到
看我上面那個case, 他們用著hibernate, 最後也是硬生生從hibernate拿jdbc connection出來, 又忘記關
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 08:35 PM
|
显示全部楼层
nsda 发表于 18-4-2014 07:18 PM
老手就算不會, 什麼framework都救不到
看我上面那個case, 他們用著hibernate, 最後也是硬生生從hibernat ...
数据库那边可以在profile里面设定max_connection_timeout的。
要不然就把max session开大。但是最好还是close connection啦。
最怕就是有些人开着connection却没有commit。浪费资源
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 08:59 PM
|
显示全部楼层
gipsydanger 发表于 18-4-2014 08:35 PM
数据库那边可以在profile里面设定max_connection_timeout的。
要不然就把max session开大。但是最好还 ...
對, 後來小弟才在application side加上min_conn/max_conn/timeout, 因為db是幾個application共用的, 不想去動到db
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 09:09 PM
|
显示全部楼层
nsda 发表于 18-4-2014 08:59 PM
對, 後來小弟才在application side加上min_conn/max_conn/timeout, 因為db是幾個application共用的, 不想 ...
最常见就是insert很多很多算百万row的数据却没有commit。害到一直中shared pool size满的问题。不然就temp tbs full。骂了几次还不会改程序。还要我帮他们performance tuning。
反正就是每次不认错。要提供一大堆铁证，他们就说一句：哦，我的问题啊？酱我去改看看。
过不多久，那些问题又回来的。session每次不是太久inactive就是变成exclusive lock。不然就sequantial read。叫他们create index run index scan就每次给我full table scan,cross db scan, cartesian join, infinite loop scan。那些表每个不是100行,是千万行算亿行的。 这样跑不是跑到明年去？其他apps不用read咯？
讲了就吐血。
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 09:19 PM
|
显示全部楼层
gipsydanger 发表于 18-4-2014 09:09 PM
最常见就是insert很多很多算百万row的数据却没有commit。害到一直中shared pool size满的问题。不然就tem ...
這位大大是做banking的?
小弟也經歷過junior不加index導致一整天某間本地銀行某個process都stuck著的問題
最後是小弟去銀行被罵, 回來又要自己加, 又不能罵junior, 沒辦法, 是我監督不周
這位junior總共犯了一樣的錯誤3~4次
後來去了新公司, 我的做法是所有low level的東西都wrap起來自動幫他們做, 就不會有你所謂的沒commit, shared pool滿的問題了 |
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 09:30 PM
|
显示全部楼层
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 09:39 PM
|
显示全部楼层
4.6k developer算多了，5年了你还只是developer，试下薪水会到那里？developer薪水高也是有limit的，不如放远想做SA manager更好
还有公司要请的不是看多少年经验而是你的本事 本帖最后由 ck_07 于 18-4-2014 09:40 PM 编辑
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 09:44 PM
|
显示全部楼层
ck_07 发表于 18-4-2014 09:39 PM
4.6k developer算多了，5年了你还只是developer，试下薪水会到那里？developer薪水高也是有limit的，不如放 ...
developer薪水可以很高的...我3年經驗時就被counter offer過8k, 不過我沒接受
薪水10k的developer也看過幾個
不過重點還是看個人興趣, 不然很難持續下去
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 09:47 PM
|
显示全部楼层
nsda 发表于 18-4-2014 09:44 PM
developer薪水可以很高的...我3年經驗時就被counter offer過8k, 不過我沒接受
薪水10k的developer也看過 ...
.net 比较难吧，除非ERP，你做什么的？
对呀，兴趣很重要 |
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 09:50 PM
|
显示全部楼层
ck_07 发表于 18-4-2014 09:47 PM
.net 比较难吧，除非ERP，你做什么的？
对呀，兴趣很重要
目前什麼都做, 用java
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 10:36 PM
|
显示全部楼层
gipsydanger 发表于 18-4-2014 08:35 PM
数据库那边可以在profile里面设定max_connection_timeout的。
要不然就把max session开大。但是最好还 ...
max out db connection 只是治标不治本。。。 stress test 时不爆， 到 production 时才爆就爽鸟， 要不然就 1 年后才爆 ～ 呵呵。。。
可以去找些 code scanning tool, check in 时 scan 一下, bad practices, 忘记那个忘记这个的全部 list 出来... findbug, PMD, sonnaJ etc 很多都很好下的 呵呵呵 本帖最后由 pcstory 于 18-4-2014 10:39 PM 编辑
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 10:40 PM
|
显示全部楼层
gipsydanger 发表于 18-4-2014 09:30 PM
没有commit还是出问题，rollback太久也会导致table lock。而且不能kill session。除非你直接把apps断线， ...
有时候看到到处都是 index 时。。。 可能是 design DB structure 时 normalization 作到不够好 。。。 不过normalize 过度,作report 的 query 的会吐血呵呵 ～
不过如果有 reporting data mart 的可以那边 denormalize... 不过这样又不能有 real time reporting... 唉。。。 一切都要 balance...
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 10:52 PM
|
显示全部楼层
gipsydanger 发表于 18-4-2014 09:09 PM
最常见就是insert很多很多算百万row的数据却没有commit。害到一直中shared pool size满的问题。不然就tem ...
我那时做 calculation 时... 是跟据 history records, 看 size, define 好 batch 的 steps，一个 stage 一个 stage commit 在 staging tables 而已, 全部 stages success 了， 在 pure insert/update 到 main tables 就好了。。。变成我用自己的 commit stategy :p .... ... 每天一开始时全部 staging tables 一起 drop, re-create, start process... ... 要不然那个 hardware 那边 不懂要加多少 RAM 和 disk 给我 呵呵呵呵呵。。。
|
|
|
|
|
|
|
|
|
|
|
|
发表于 18-4-2014 10:58 PM
|
显示全部楼层
nsda 发表于 18-4-2014 07:11 PM
我也看過一個本地大型零售商的internal system的code
每個crud都會create一個hibernate的factory, 最死是 ...
那种每次因为 performance 慢就 reboot server 的，根本没有做 application health check, vm profiling, db health check...大型的 system 不做这种。。。会很难 scale 的。。。 不过越来越少人重视这种的了。。。 processor 和 ram 酱便宜， upgrade 咯。。。以为 upgrade 就解决的了问题呵呵呵。。。
还有，真行。。。 选了 hibernate 还不好好研究， 一堆 documentation 还有书。。。你讲那些也是极品来的 呵呵呵呵呵 ～ 本帖最后由 pcstory 于 18-4-2014 11:35 PM 编辑
|
|
|
|
|
|
|
|
|
|
|
|
发表于 20-4-2014 11:42 AM
|
显示全部楼层
如果能为公司年赚100k，公司还可以给5k的月薪，
当要求别人付你高薪的时候，先问问你能为公司带来多少的盈利
你在公司的存在价值，会直接反映在你的薪水上
|
|
|
|
|
|
|
|
|
|
| |
 本周最热论坛帖子
|
3962 
65
